exploring changes to Mylyn Docs build

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

exploring changes to Mylyn Docs build

David Green-15
Devs,

I've been experimenting with restructuring the Mylyn Docs build to achieve a few things:

* easier to build/release Mylyn Docs (or at least Mylyn WikiText) separately from Mylyn
* easier to consume Mylyn WikiText core bundles (e.g. as plain jars, with normal poms)
* easier to contribute (e.g. without knowledge of OSGi or PDE)
* better structured code/tests (e.g. using normal Maven project layout)
* faster cycle time (e.g. easier to verify code changes, faster builds)

To achieve these things I've been looking at building the "core" wikitext bundles as normal Maven artifacts, using a Maven plug-in to generate OSGi manifests.

You can see the results of my experiment here: https://github.com/greensopinion/mylyn.docs

The build is split into two parts: a "core" part which is Tycho-less, and a UI/OSGi part which uses Tycho.

I'd love to get your thoughts and feedback on the goals and the approach.

David


--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [mylyn-docs-dev] exploring changes to Mylyn Docs build

Torkild U. Resheim
David,

Although I have not yet inspected at your code, I fully support this. There is already some discussion going on in making Eclipse code consumable through Maven, I think you’re probably aware of this. So the timing is impeccable :-) Btw. the EPUB part should also be fairly straightforward to build in this way, although it does rely on EMF.

I think to easily being able to consume WikiText outside Eclipse is a great idea. It believe it will convince more people to use it. I’ve already done two web service projects where it’s used to render markup on the fly. Works like a charm, but I had to include the binaries in the project.

I think splitting it up like you describe makes good sense. The UI part is only usable in a RCP environment anyway.

Best regards,
Torkild

> 2. des. 2016 kl. 18.47 skrev David Green <[hidden email]>:
>
> Devs,
>
> I've been experimenting with restructuring the Mylyn Docs build to achieve a few things:
>
> * easier to build/release Mylyn Docs (or at least Mylyn WikiText) separately from Mylyn
> * easier to consume Mylyn WikiText core bundles (e.g. as plain jars, with normal poms)
> * easier to contribute (e.g. without knowledge of OSGi or PDE)
> * better structured code/tests (e.g. using normal Maven project layout)
> * faster cycle time (e.g. easier to verify code changes, faster builds)
>
> To achieve these things I've been looking at building the "core" wikitext bundles as normal Maven artifacts, using a Maven plug-in to generate OSGi manifests.
>
> You can see the results of my experiment here: https://github.com/greensopinion/mylyn.docs
>
> The build is split into two parts: a "core" part which is Tycho-less, and a UI/OSGi part which uses Tycho.
>
> I'd love to get your thoughts and feedback on the goals and the approach.
>
> David
>
>
> --
>
> David Green | VP of Architecture | Tasktop
> email: [hidden email]
> _______________________________________________
> mylyn-docs-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev

_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [mylyn-docs-dev] exploring changes to Mylyn Docs build

David Green-15
Thanks Torkild, great to hear.

On Fri, Dec 2, 2016 at 11:03 AM Torkild Ulvøy Resheim <[hidden email]> wrote:
David,

Although I have not yet inspected at your code, I fully support this. There is already some discussion going on in making Eclipse code consumable through Maven, I think you’re probably aware of this. So the timing is impeccable :-) Btw. the EPUB part should also be fairly straightforward to build in this way, although it does rely on EMF.

I think to easily being able to consume WikiText outside Eclipse is a great idea. It believe it will convince more people to use it. I’ve already done two web service projects where it’s used to render markup on the fly. Works like a charm, but I had to include the binaries in the project.

I think splitting it up like you describe makes good sense. The UI part is only usable in a RCP environment anyway.

Best regards,
Torkild
> 2. des. 2016 kl. 18.47 skrev David Green <[hidden email]>:
>
> Devs,
>
> I've been experimenting with restructuring the Mylyn Docs build to achieve a few things:
>
> * easier to build/release Mylyn Docs (or at least Mylyn WikiText) separately from Mylyn
> * easier to consume Mylyn WikiText core bundles (e.g. as plain jars, with normal poms)
> * easier to contribute (e.g. without knowledge of OSGi or PDE)
> * better structured code/tests (e.g. using normal Maven project layout)
> * faster cycle time (e.g. easier to verify code changes, faster builds)
>
> To achieve these things I've been looking at building the "core" wikitext bundles as normal Maven artifacts, using a Maven plug-in to generate OSGi manifests.
>
> You can see the results of my experiment here: https://github.com/greensopinion/mylyn.docs
>
> The build is split into two parts: a "core" part which is Tycho-less, and a UI/OSGi part which uses Tycho.
>
> I'd love to get your thoughts and feedback on the goals and the approach.
>
> David
>
>
> --
>
> David Green | VP of Architecture | Tasktop
> email: [hidden email]
> _______________________________________________
> mylyn-docs-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev

_______________________________________________
mylyn-docs-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev
--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [mylyn-docs-dev] exploring changes to Mylyn Docs build

David Green-15
In reply to this post by David Green-15
All,

The build change experiment is coming together and I want to be sure that I close the loop before proceeding.  You can see what I've done so far here: 


There is now a single-command build as detailed in the readme.

See the discussion below on this thread for detail about trade-offs. I think it's worth moving ahead with this knowing that the UI development workflow is not perfect, but your opinion may differ so please let me know if you think we should hold off.

David

On Mon, Dec 5, 2016 at 11:40 AM David Green <[hidden email]> wrote:
Stephan,

With the proposed changes as-is, that would not be possible.  You'd have to run a maven build on the core bundles and then refresh the projects and/or target platform to consume the changes.  This workflow is definitely suboptimal.

If we make it easier to write unit tests and run them, it will become a lot easier to debug core portions of the codebase without having to fire up an IDE from your workspace.  At least that's my hope with the Maven project layout.

I've  found that we're spending less time working on RCP/UI portions of the codebase and more on the core portions.  
At least for me, this would be an acceptable trade-off.  What do you think?

David

On Sat, Dec 3, 2016 at 1:19 PM Stephan Wahlbrink <[hidden email]> wrote:
Hi David,

[2016-12-02 18:47] David Green wrote:
> Devs,
>
> I've been experimenting with restructuring the Mylyn Docs build to
> achieve a few things:
>
> * easier to build/release Mylyn Docs (or at least Mylyn WikiText)
> separately from Mylyn
> * easier to consume Mylyn WikiText core bundles (e.g. as plain jars,
> with normal poms)
> * easier to contribute (e.g. without knowledge of OSGi or PDE)
> * better structured code/tests (e.g. using normal Maven project layout)
> * faster cycle time (e.g. easier to verify code changes, faster builds)
>
> To achieve these things I've been looking at building the "core"
> wikitext bundles as normal Maven artifacts, using a Maven plug-in to
> generate OSGi manifests.

How can I consume such m2e source projects directly as osgi bundles in a
PDE workspace / PDE build? (use case: debugging Mylyn WikiText core
bundles in an RCP application)

Stephan


> You can see the results of my experiment here:
> https://github.com/greensopinion/mylyn.docs
>
> The build is split into two parts: a "core" part which is Tycho-less,
> and a UI/OSGi part which uses Tycho.
>
> I'd love to get your thoughts and feedback on the goals and the approach.
>
> David
>
>
> --
>
> *
> *
>
> *David Green **|** *VP of Architecture* **| *Tasktop
>
> *email: *[hidden email] <mailto:[hidden email]>
>
>
>
> _______________________________________________
> mylyn-docs-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev
>
_______________________________________________
mylyn-docs-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev
--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [mylyn-docs-dev] exploring changes to Mylyn Docs build

Sam Davis
Before responding, I want to point out that I'm not a Mylyn Docs committer. I'm just offering my thoughts for consideration.

I don't feel strongly about this decision but I do question some of the claimed benefits:
 
* easier to contribute (e.g. without knowledge of OSGi or PDE)

I would argue that most contributions don't actually require any knowledge of OSGi or PDE. For larger contributions, the knowledge required is usually just how to add dependencies to a manifest, which shouldn't be an obstacle for someone invested enough to make a large contribution.

* better structured code/tests (e.g. using normal Maven project layout)

I don't think that following a different convention is "better," just different.
 
* faster cycle time (e.g. easier to verify code changes, faster builds)

Is there any data to support this? This should be weighed against the increased friction of needing to run a maven build when debugging. It seems to me that this will affect all development on WikiText, not just UI development.

Is there a way to have the best of both worlds by enabling the core to be built using either Maven or PDE? This would probably add a little maintenance cost but the smoother development workflow might be worth it.

Cheers,
Sam


--
Sam Davis
Senior Software Engineer, Tasktop
Committer, Eclipse Mylyn
http://tasktop.com

On Tue, Jan 24, 2017 at 4:55 PM, David Green <[hidden email]> wrote:
All,

The build change experiment is coming together and I want to be sure that I close the loop before proceeding.  You can see what I've done so far here: 


There is now a single-command build as detailed in the readme.

See the discussion below on this thread for detail about trade-offs. I think it's worth moving ahead with this knowing that the UI development workflow is not perfect, but your opinion may differ so please let me know if you think we should hold off.

David


On Mon, Dec 5, 2016 at 11:40 AM David Green <[hidden email]> wrote:
Stephan,

With the proposed changes as-is, that would not be possible.  You'd have to run a maven build on the core bundles and then refresh the projects and/or target platform to consume the changes.  This workflow is definitely suboptimal.

If we make it easier to write unit tests and run them, it will become a lot easier to debug core portions of the codebase without having to fire up an IDE from your workspace.  At least that's my hope with the Maven project layout.

I've  found that we're spending less time working on RCP/UI portions of the codebase and more on the core portions.  
At least for me, this would be an acceptable trade-off.  What do you think?

David

On Sat, Dec 3, 2016 at 1:19 PM Stephan Wahlbrink <[hidden email]> wrote:
Hi David,

[2016-12-02 18:47] David Green wrote:
> Devs,
>
> I've been experimenting with restructuring the Mylyn Docs build to
> achieve a few things:
>
> * easier to build/release Mylyn Docs (or at least Mylyn WikiText)
> separately from Mylyn
> * easier to consume Mylyn WikiText core bundles (e.g. as plain jars,
> with normal poms)
> * easier to contribute (e.g. without knowledge of OSGi or PDE)
> * better structured code/tests (e.g. using normal Maven project layout)
> * faster cycle time (e.g. easier to verify code changes, faster builds)
>
> To achieve these things I've been looking at building the "core"
> wikitext bundles as normal Maven artifacts, using a Maven plug-in to
> generate OSGi manifests.

How can I consume such m2e source projects directly as osgi bundles in a
PDE workspace / PDE build? (use case: debugging Mylyn WikiText core
bundles in an RCP application)

Stephan


> You can see the results of my experiment here:
> https://github.com/greensopinion/mylyn.docs
>
> The build is split into two parts: a "core" part which is Tycho-less,
> and a UI/OSGi part which uses Tycho.
>
> I'd love to get your thoughts and feedback on the goals and the approach.
>
> David
>
>
> --
>
> *
> *
>
> *David Green **|** *VP of Architecture* **| *Tasktop
>
> *email: *[hidden email] <mailto:[hidden email]>
>
>
>
> _______________________________________________
> mylyn-docs-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev
>
_______________________________________________
mylyn-docs-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev
--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-docs-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev


_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [mylyn-docs-dev] exploring changes to Mylyn Docs build

David Green-15
Sam,

Thanks for your input!  

I've added my two cents inline below:

On Wed, Jan 25, 2017 at 12:52 PM Sam Davis <[hidden email]> wrote:
Before responding, I want to point out that I'm not a Mylyn Docs committer. I'm just offering my thoughts for consideration.

I don't feel strongly about this decision but I do question some of the claimed benefits:
 
* easier to contribute (e.g. without knowledge of OSGi or PDE)

I would argue that most contributions don't actually require any knowledge of OSGi or PDE. For larger contributions, the knowledge required is usually just how to add dependencies to a manifest, which shouldn't be an obstacle for someone invested enough to make a large contribution.

Updating manifests isn't something a Java developer would normally have to do in a "plain" Java project.  Also, consider the project layout - a Maven layout is widespread and commonly used.  Only people exposed to OSGi or Eclipse development would know about bundles and tests that exist in separate projects.

Additionally, consider that anyone maintaining the build would have to understand how the build works.  Reducing that overhead at least for the core components could be beneficial.
 

* better structured code/tests (e.g. using normal Maven project layout)

I don't think that following a different convention is "better," just different.

This is like the vi versus emacs discussion, everyone has an opinion.  I really only meant in the sense that the Maven convention is more widespread, it's better.
 
 
* faster cycle time (e.g. easier to verify code changes, faster builds)

Is there any data to support this?

Anecdotally, running the Maven-based build was quite a lot faster for me.  I'm able to run a Maven build of just the WikiText core in 49 seconds versus 21 minutes for all of Mylyn Docs using a tycho-based build.  This isn't an apples-to-apples comparison, but demonstrates some of the potential benefits.
 
This should be weighed against the increased friction of needing to run a maven build when debugging. It seems to me that this will affect all development on WikiText, not just UI development.

There is no need to run a Maven build when debugging.

The trade-off outlined below is that UI development would have an additional step of running the Maven-based build once to get the core bundles into the target platform.  Alternatively that step could be avoided by installing WikiText into Eclipse and using the running platform as the target.

Development of the core components of WikiText (the headless, non-eclipsy parts) would be the same as developing for any other Maven-based Java project.  It wouldn't even be necessary to have PDE installed, or to use Eclipse for that matter.
 

Is there a way to have the best of both worlds by enabling the core to be built using either Maven or PDE? This would probably add a little maintenance cost but the smoother development workflow might be worth it.

I'm sure there is a way - but I'm not keen on maintaining two separate build systems.

David
 

Cheers,
Sam


--
Sam Davis
Senior Software Engineer, Tasktop
Committer, Eclipse Mylyn
http://tasktop.com

On Tue, Jan 24, 2017 at 4:55 PM, David Green <[hidden email]> wrote:
All,

The build change experiment is coming together and I want to be sure that I close the loop before proceeding.  You can see what I've done so far here: 


There is now a single-command build as detailed in the readme.

See the discussion below on this thread for detail about trade-offs. I think it's worth moving ahead with this knowing that the UI development workflow is not perfect, but your opinion may differ so please let me know if you think we should hold off.

David


On Mon, Dec 5, 2016 at 11:40 AM David Green <[hidden email]> wrote:
Stephan,

With the proposed changes as-is, that would not be possible.  You'd have to run a maven build on the core bundles and then refresh the projects and/or target platform to consume the changes.  This workflow is definitely suboptimal.

If we make it easier to write unit tests and run them, it will become a lot easier to debug core portions of the codebase without having to fire up an IDE from your workspace.  At least that's my hope with the Maven project layout.

I've  found that we're spending less time working on RCP/UI portions of the codebase and more on the core portions.  
At least for me, this would be an acceptable trade-off.  What do you think?

David

On Sat, Dec 3, 2016 at 1:19 PM Stephan Wahlbrink <[hidden email]> wrote:
Hi David,

[2016-12-02 18:47] David Green wrote:
> Devs,
>
> I've been experimenting with restructuring the Mylyn Docs build to
> achieve a few things:
>
> * easier to build/release Mylyn Docs (or at least Mylyn WikiText)
> separately from Mylyn
> * easier to consume Mylyn WikiText core bundles (e.g. as plain jars,
> with normal poms)
> * easier to contribute (e.g. without knowledge of OSGi or PDE)
> * better structured code/tests (e.g. using normal Maven project layout)
> * faster cycle time (e.g. easier to verify code changes, faster builds)
>
> To achieve these things I've been looking at building the "core"
> wikitext bundles as normal Maven artifacts, using a Maven plug-in to
> generate OSGi manifests.

How can I consume such m2e source projects directly as osgi bundles in a
PDE workspace / PDE build? (use case: debugging Mylyn WikiText core
bundles in an RCP application)

Stephan


> You can see the results of my experiment here:
> https://github.com/greensopinion/mylyn.docs
>
> The build is split into two parts: a "core" part which is Tycho-less,
> and a UI/OSGi part which uses Tycho.
>
> I'd love to get your thoughts and feedback on the goals and the approach.
>
> David
>
>
> --
>
> *
> *
>
> *David Green **|** *VP of Architecture* **| *Tasktop
>
> *email: *[hidden email] <mailto:[hidden email]>
>
>
>
> _______________________________________________
> mylyn-docs-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev
>
_______________________________________________
mylyn-docs-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev
--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-docs-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev

_______________________________________________
mylyn-docs-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-docs-dev
--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exploring changes to Mylyn Docs build

David Green-15
In reply to this post by David Green-15
All,

I've opened the following bug to track this effort:


You can see the results of what I've done so far, with this review being the tip of the chain: https://git.eclipse.org/r/#/c/89651/
Note that some of the changes don't build - only from the last review does the whole chain build properly.

Some things left to do:

* iterate as needed to improve the changes until we're ready to merge
* update sites - do we want WikiText in the Mylyn Docs site or separate?
* determine where and how to publish the Maven artifacts from the core part of the build
* update build jobs accordingly (Gerrit review verification, snapshot and release builds)
* determine if or how this affects EPP contributions

I'd appreciate your feedback on the bug or on the reviews.

Thanks,

David

On Fri, Dec 2, 2016 at 9:47 AM David Green <[hidden email]> wrote:
Devs,

I've been experimenting with restructuring the Mylyn Docs build to achieve a few things:

* easier to build/release Mylyn Docs (or at least Mylyn WikiText) separately from Mylyn
* easier to consume Mylyn WikiText core bundles (e.g. as plain jars, with normal poms)
* easier to contribute (e.g. without knowledge of OSGi or PDE)
* better structured code/tests (e.g. using normal Maven project layout)
* faster cycle time (e.g. easier to verify code changes, faster builds)

To achieve these things I've been looking at building the "core" wikitext bundles as normal Maven artifacts, using a Maven plug-in to generate OSGi manifests.

You can see the results of my experiment here: https://github.com/greensopinion/mylyn.docs

The build is split into two parts: a "core" part which is Tycho-less, and a UI/OSGi part which uses Tycho.

I'd love to get your thoughts and feedback on the goals and the approach.

David


--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Mylyn Docs build changes (was Re: exploring changes to Mylyn Docs build)

David Green-15
All,

I plan to merge the review chain ending with https://git.eclipse.org/r/90016 today.  I will also make the corresponding changes to the Mylyn Docs nightly build here: https://hudson.eclipse.org/mylyn/view/Nightlies/job/mylyn-docs-nightly/

There is a chance that other builds could break, we should find out quickly.

The folder structure in the Mylyn Docs git repository will be different after merging.  As a result anyone with Mylyn Docs checked out into their Eclipse workspace will want to delete all Mylyn Docs projects from their workspace before pulling the changes, and then reimport those projects.  Gerrit reviews will also need rebasing.

I just discussed these changes with Sam and Steffen and it looks like these changes will cause the Mylyn release build to fail, since the Mylyn release build relies on having a single Maven reactor.

To overcome this problem Sam's suggestion is to switch the Mylyn Git submodule to point to Mylyn Docs at a specific commit until such time as the Mylyn release build has been decoupled.  A Mylyn committer will have to do this.

Apologies in advance for any trouble this causes, hopefully we can get through this change quickly.

David

On Thu, Jan 26, 2017 at 2:40 PM David Green <[hidden email]> wrote:
All,

I've opened the following bug to track this effort:


You can see the results of what I've done so far, with this review being the tip of the chain: https://git.eclipse.org/r/#/c/89651/
Note that some of the changes don't build - only from the last review does the whole chain build properly.

Some things left to do:

* iterate as needed to improve the changes until we're ready to merge
* update sites - do we want WikiText in the Mylyn Docs site or separate?
* determine where and how to publish the Maven artifacts from the core part of the build
* update build jobs accordingly (Gerrit review verification, snapshot and release builds)
* determine if or how this affects EPP contributions

I'd appreciate your feedback on the bug or on the reviews.

Thanks,

David


On Fri, Dec 2, 2016 at 9:47 AM David Green <[hidden email]> wrote:
Devs,

I've been experimenting with restructuring the Mylyn Docs build to achieve a few things:

* easier to build/release Mylyn Docs (or at least Mylyn WikiText) separately from Mylyn
* easier to consume Mylyn WikiText core bundles (e.g. as plain jars, with normal poms)
* easier to contribute (e.g. without knowledge of OSGi or PDE)
* better structured code/tests (e.g. using normal Maven project layout)
* faster cycle time (e.g. easier to verify code changes, faster builds)

To achieve these things I've been looking at building the "core" wikitext bundles as normal Maven artifacts, using a Maven plug-in to generate OSGi manifests.

You can see the results of my experiment here: https://github.com/greensopinion/mylyn.docs

The build is split into two parts: a "core" part which is Tycho-less, and a UI/OSGi part which uses Tycho.

I'd love to get your thoughts and feedback on the goals and the approach.

David


--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mylyn Docs build changes (was Re: exploring changes to Mylyn Docs build)

David Green-15
All,

The changes are merged, and the nightly has completed successfully: https://hudson.eclipse.org/mylyn/view/Nightlies/job/mylyn-docs-nightly/

In order to get that build working, I had to change the goal from deploy to verify.  This means that the nightly build is no longer deploying to the snapshot repository, something that we'll have to figure out.

I'll keep the bug open https://bugs.eclipse.org/bugs/show_bug.cgi?id=511120 since there is still some work to do.

David

On Tue, Jan 31, 2017 at 3:36 PM David Green <[hidden email]> wrote:
All,

I plan to merge the review chain ending with https://git.eclipse.org/r/90016 today.  I will also make the corresponding changes to the Mylyn Docs nightly build here: https://hudson.eclipse.org/mylyn/view/Nightlies/job/mylyn-docs-nightly/

There is a chance that other builds could break, we should find out quickly.

The folder structure in the Mylyn Docs git repository will be different after merging.  As a result anyone with Mylyn Docs checked out into their Eclipse workspace will want to delete all Mylyn Docs projects from their workspace before pulling the changes, and then reimport those projects.  Gerrit reviews will also need rebasing.

I just discussed these changes with Sam and Steffen and it looks like these changes will cause the Mylyn release build to fail, since the Mylyn release build relies on having a single Maven reactor.

To overcome this problem Sam's suggestion is to switch the Mylyn Git submodule to point to Mylyn Docs at a specific commit until such time as the Mylyn release build has been decoupled.  A Mylyn committer will have to do this.

Apologies in advance for any trouble this causes, hopefully we can get through this change quickly.

David

On Thu, Jan 26, 2017 at 2:40 PM David Green <[hidden email]> wrote:
All,

I've opened the following bug to track this effort:


You can see the results of what I've done so far, with this review being the tip of the chain: https://git.eclipse.org/r/#/c/89651/
Note that some of the changes don't build - only from the last review does the whole chain build properly.

Some things left to do:

* iterate as needed to improve the changes until we're ready to merge
* update sites - do we want WikiText in the Mylyn Docs site or separate?
* determine where and how to publish the Maven artifacts from the core part of the build
* update build jobs accordingly (Gerrit review verification, snapshot and release builds)
* determine if or how this affects EPP contributions

I'd appreciate your feedback on the bug or on the reviews.

Thanks,

David


On Fri, Dec 2, 2016 at 9:47 AM David Green <[hidden email]> wrote:
Devs,

I've been experimenting with restructuring the Mylyn Docs build to achieve a few things:

* easier to build/release Mylyn Docs (or at least Mylyn WikiText) separately from Mylyn
* easier to consume Mylyn WikiText core bundles (e.g. as plain jars, with normal poms)
* easier to contribute (e.g. without knowledge of OSGi or PDE)
* better structured code/tests (e.g. using normal Maven project layout)
* faster cycle time (e.g. easier to verify code changes, faster builds)

To achieve these things I've been looking at building the "core" wikitext bundles as normal Maven artifacts, using a Maven plug-in to generate OSGi manifests.

You can see the results of my experiment here: https://github.com/greensopinion/mylyn.docs

The build is split into two parts: a "core" part which is Tycho-less, and a UI/OSGi part which uses Tycho.

I'd love to get your thoughts and feedback on the goals and the approach.

David


--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]

--


David Green | VP of Architecture Tasktop

email: [hidden email]


_______________________________________________
mylyn-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mylyn-dev
Loading...