Allow simple full chained build #171
Comments
|
On 18 avr. 2014, at 15:01, Nicolas Delsaux [email protected] wrote:
|
|
Even with a well defined set of dependencies ? |
|
On 18 avr. 2014, at 15:14, Nicolas Delsaux [email protected] wrote:
|
|
OK, let me experiment with it a little (unless you've already tried all your maven-fu ?) |
|
On 18 avr. 2014, at 15:18, Nicolas Delsaux [email protected] wrote:
If you find a way to fix this, I pay you at least a dozen of beer…
|
|
Hrm Do you want the pull request to check that by yourself ? I'm not yet sure if absolutely all components have been correctly compiled ... |
|
From an empty Maven repo ? On 18 avr. 2014, at 15:31, Nicolas Delsaux [email protected] wrote:
|
|
Aw crap, i forgot that 👍 |
|
That's indeed a different story : |
|
However, once installed in your repo, and as soon as you don’t change the lifecycle mapping, it works…. So, most of the time, it’s ok ;-) On 18 avr. 2014, at 15:37, Nicolas Delsaux [email protected] wrote:
|
|
Yeah, in fact it would require developpers to run a |
|
That’s why the release process is so…. dreadful On 18 avr. 2014, at 15:45, Nicolas Delsaux [email protected] wrote:
|
|
Well, after having read the maven doc a little, i must agree with you : build process is insane :-) In fact, latest comment of @aheritier gives the official workaround to apply : My proposal woud be to have
This way, the release would be simplified into two project releases. Obviously, for the sake of consistency, What do you think about that ? |
|
It would be great to have such structure. Just before the last release, we discussed this a little bit. The main issue is that having a second repository leads to have two issue trackers, and so on. I would prefer keeping only one issue tracker (just because, I create dozen of issues every day, and I don’t want to think which tracker I have to use). There is another point that can be interesting to look a bit deeper: git modules. My experience with them is small (to not say inexistent). Maybe we can check if we can use sub modules to link the core within the runtime. But every effort made to simplify our build process is more than welcome. On 18 avr. 2014, at 16:18, Nicolas Delsaux [email protected] wrote:
|
…en renamed into wisdom/documentation-base Technical reason is that maven doesn't allow two modules having the same artifactId and, as a convention, modules are named after the containing folder. As a consequence, I had two choices : - rename wisdom/documentation into documentation-base - renamed documentation/documentation into .... what ? I choosed the first because it's only the parent folder, and not the effective artifact which will contain browsable documentation (well, also because i had no idea of a valid name for the second one).
Building wisdom is now a three-step build : 1 - Go into your wisdom/wisdom-framework folder and "mvn install". It will build wisdom framework base pom. This pom is used by both core and components, and define common dependencies, and so on 2 - Go into your wisdom/core folder and "mvn install". it will build wisdom core (and the in-famous maven plugin) 3 - Then go into wisdom/components subfolder and "mvn install". it will build framework, extensions and documentation-base (in this order) How release work ? Well, exactly the same way, excpeted one also need to change reference to wisdom-framework parent pom in core and components poms before trying to release them. Having no experience of such a splitted release with git, I don't know which form the tags/branchs will take .. However, i think it is by far simpler than current build process. in fact, the only thing missing would be a shortcut in root folder allowing one to call all three maven builds.
|
The main issue with your fix is the release tag. It will generate two 'incomplete' tags. Git tags are a view of the complete repository, meaning that if we release the core, the tag contains snapshot versions of the runtime. So tags are not 'full build'. That's why I was mentioning the fact to have a separated project because it's the only way to get the release tag working. |
|
So, to sum up here are the possibilities:
WDYT ? |
|
I've met @jponge yesterday and he had the same issue in golo-lang. He use a Rake file to ease the bug. Might be a solution. The rake file is here: https://github.com/golo-lang/golo-lang/blob/master/Rakefile |
Currently, bulding wisdom must be done in 4 steps :
mvn -Pcoremvn -Pframeworkmvn -Pextensionsmvn -PextensionsCould it be possible to have one full build when no profile is specified ?
The text was updated successfully, but these errors were encountered: