maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <jo...@j-hohwiller.de>
Subject Re: Progress on support for large projects
Date Sun, 10 May 2009 13:09:50 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> Hi there,

thanks for your answer...

>> 
>> absolutely everybody having large maven projects is
>> annoyed by maintaining the versions in all the poms.
>> 
>> 
> Are you using the release plugin?

Nope! I tried it and came to the point that is no good for me.
I also had a discussion with the developers long time ago
and filed some feature request. Anyhow I still think this
is the wrong approach for me.

>> 
>> 
>> Additionally the complete solution is quite simple
>> and seems to be quite common sense:
>> 
>> 1. Allow to omitt versions in <parent> as well
>> as in <dependency> that is available in the reactor.
>> 
>> 
> Omitting the parent is complicated. Ralph started an implementation but we
> found some issues with it at ApacheCon. I don't think it's gotten beyond
> that yet.

I have read parts of this. I hope there is a chance to see this in the
future.

> 
>> You can use dependency management or properties to deal with omitting the
>> dependencies. I personally never assume what will be contained in a reactor
>> and structure my builds so that any module can always be built in isolation.
>> Therefore, I can't see why you would want to omit the dependency for
>> something in a reactor that may not be in the reactor all the time. The
>> release plugin handles this for you when it's time to bump the versions.

I see your point. But I am always building from toplevel.
Anyhow I am also dreaming of a cmd-option in maven 3 that enables
a mode where maven walks up to the loplevel pom (as far as locally
available) and creates the entire reactor while still building
just the module where it was invoked. This could solve the problem you
pointed out as well as many other problems, e.g. to do dependent builds
of local modules.

Anyhow this would just be a feature that does not hurt and
would not cause downward compatibility problems if assured,
that install/deploy will fill in the omitted version.


>> 
>> 
>> 2. Ensure that omitted version as well as variables
>> in <groupId> <artifactId> and <version> are replaced
>> when a pom is installed in the repository.
>> 
>> 
> Agree with this.

Great. So I hope for MNG-2971. Anybody out there
can let me know if this is just waiting for contribution.
I might work on this one if it is just about that feature
in the install-plugin. If there is some more general architectural
change needed in order to make this also work with release-plugin
and many others let me know - I might not see all possible problems.
I think I also read some ideas about POM-Transformation in maven 3...

>> 
>> 
>> However I totally lost where we are and what is going on.
>> 
>> http://jira.codehaus.org/browse/MNG-624
>> http://jira.codehaus.org/browse/MNG-2971
>> http://jira.codehaus.org/browse/MNG-3267
>> http://jira.codehaus.org/browse/MNG-2971
>> 
>> I could not find the one to omitt version in <depdency>.
>> Can anybody remember. Or do I have to open a new one.
>> 
>> I can not really tell how hard it is to make this
>> work, but be sure that we can make millions of users
>> happy with this!
>> 
>> Thanks
>>  Jörg

Regards
  Jörg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoG0h4ACgkQmPuec2Dcv/8zqgCghlevEs/YlVRLaaTIWQl6yi5W
kJYAn00C5R0sjXjIl6Z08EtMCFEFIMHN
=yhX0
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message