Re: Progress on support for large projects

[Barrie Treloar]

On Sat, May 16, 2009 at 5:17 AM, Joerg Hohwiller  wrote:
>> Off topic.
>>
>> Actually I believe this isn't true anymore.
>>
>> See http://jira.codehaus.org/browse/MECLIPSE-344
[del]
>> mvn eclipse:eclipse will make sure my module pA references the eclipse
>> project for module cA (and not the jar of cA in the repo)
>
> Thanks for the hint!
> But only works if eclipse-plugin knows where my workspace is.
> The location may be different for each developer so I can NOT
> truly automate. Anyhow I will start using this.
> At least better solution than what I had before.

With 2.6 
(http://maven.apache.org/plugins/maven-eclipse-plugin-2.6/eclipse-mojo.html#workspace)
if the workspace variable is not defined then m-e-p will walk up the
directory hierarchy attempting to locate your workspace. As a general
rule people checkout their projects underneath an eclipse workspace so
it will find it automatically.  Otherwise you will need to specify it
manually.

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

Re: Progress on support for large projects

[Brian Fox]

Also be aware that 2.1/2.2 already do some pom transformations, so this
would have to extend instead of replicate what's already there.

On Sat, May 16, 2009 at 5:14 PM, Ralph Goers wrote:

>
> On May 16, 2009, at 1:48 PM, Joerg Hohwiller wrote:
>
>  -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi Ralph,
>>
>>
 Okay. So thats what I guessed when I said that the MavenProject/Model is
 just a stupid POJO and various plugins manipulate it with side effects.
 Sounds a little hacky to me but thats the way it is. So my serialization
 idea is nuts though.

 Anyhow I think that if you have some information in memory, you should
 NOT have to write it to the disc so that someone else can copy (read
 and write)
 it again. I thought that you store the transformed XML in that new
 string
 attribute (was it alternativeRepresentation) so the Installer/Deployer
 could write this string if available instead of copying the pom.xml as
 is.

>>>
>>> I think you are referring to one of the other patches that was
>>> submitted, not what I committed to the MNG-624 branch.
>>>


 A big problem could be the encoding issue if you store XML in a string
 and then want to save it with some Writer, you need to know the encoding
 from the XML-header or you run into trouble.

>>>
>>> My fix didn't store the XML in a string, it modified the DOM.
>>>
>>>  After getting more of the big picture, I think your idea is good to
>> write a new pom.xml to ${project.build.directory} and copy that on
>> install/deploy. This would also solve the needs behind something like
>> MINSTALL-50 (e.g. by some plugin that does a post-transformation on the
>> new pom).
>>
>>  Yup. That is exactly what it does, except the fix currently doesn't use
> ${project.build.directory} but just uses "trunk". This needs to be fixed.
> And as Brian mentioned it doesn't look at the -f option. If those two issues
> are resolved then this fix would just need to be integrated into the current
> 2.1 or 2.2 branch.  You are welcome to look at it and propose a way to fix
> those issues.
>
> Ralph
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Progress on support for large projects

[Ralph Goers]

On May 16, 2009, at 1:48 PM, Joerg Hohwiller wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ralph,



Okay. So thats what I guessed when I said that the MavenProject/ 
Model is
just a stupid POJO and various plugins manipulate it with side  
effects.
Sounds a little hacky to me but thats the way it is. So my  
serialization

idea is nuts though.

Anyhow I think that if you have some information in memory, you  
should

NOT have to write it to the disc so that someone else can copy (read
and write)
it again. I thought that you store the transformed XML in that new  
string
attribute (was it alternativeRepresentation) so the Installer/ 
Deployer
could write this string if available instead of copying the  
pom.xml as

is.


I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.



A big problem could be the encoding issue if you store XML in a  
string
and then want to save it with some Writer, you need to know the  
encoding

from the XML-header or you run into trouble.


My fix didn't store the XML in a string, it modified the DOM.


After getting more of the big picture, I think your idea is good to
write a new pom.xml to ${project.build.directory} and copy that on
install/deploy. This would also solve the needs behind something like
MINSTALL-50 (e.g. by some plugin that does a post-transformation on  
the new pom).


Yup. That is exactly what it does, except the fix currently doesn't  
use ${project.build.directory} but just uses "trunk". This needs to be  
fixed. And as Brian mentioned it doesn't look at the -f option. If  
those two issues are resolved then this fix would just need to be  
integrated into the current 2.1 or 2.2 branch.  You are welcome to  
look at it and propose a way to fix those issues.


Ralph

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ralph,

>>
>> Okay. So thats what I guessed when I said that the MavenProject/Model is
>> just a stupid POJO and various plugins manipulate it with side effects.
>> Sounds a little hacky to me but thats the way it is. So my serialization
>> idea is nuts though.
>>
>> Anyhow I think that if you have some information in memory, you should
>> NOT have to write it to the disc so that someone else can copy (read
>> and write)
>> it again. I thought that you store the transformed XML in that new string
>> attribute (was it alternativeRepresentation) so the Installer/Deployer
>> could write this string if available instead of copying the pom.xml as
>> is.
> 
> I think you are referring to one of the other patches that was
> submitted, not what I committed to the MNG-624 branch.
>>
>>
>> A big problem could be the encoding issue if you store XML in a string
>> and then want to save it with some Writer, you need to know the encoding
>> from the XML-header or you run into trouble.
> 
> My fix didn't store the XML in a string, it modified the DOM.
> 
After getting more of the big picture, I think your idea is good to
write a new pom.xml to ${project.build.directory} and copy that on
install/deploy. This would also solve the needs behind something like
MINSTALL-50 (e.g. by some plugin that does a post-transformation on the new 
pom).

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

iEYEARECAAYFAkoPJrQACgkQmPuec2Dcv/+ZMwCeNp/rE8KTH0sNeVuDHQ1zeOuD
mtYAn0B6p8XlqT7oan9na/POHJ4LZ4qW
=JvQY
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Brian,
>>
>> Do you need simple IT-projects that I shall attach to MNG-4161 and related?
>>
> 
> Sample ITs for sure, and some level of detail in a proposal like these:
> http://docs.codehaus.org/display/MAVENUSER/User+Proposals
> 

here is my proposal:

http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance

Let me know if somethings missing or wrong.

BTW: is there a chance to have such feature running in a usable
version of maven (NOT a official release) in a couple of month?
If we are talking about something that will go into 3.x and is
NOT usable before 2010, I rather put my energy in a simple front-end
that handles this feature and then delegates to maven.

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

iEYEARECAAYFAkoPH6UACgkQmPuec2Dcv/8JrgCfQXNZXlA/c/NcA+aJywZ7s8bt
LJMAnjyKgoyEfhPk8k299FjJvLS7l8j3
=xAY4
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Brian Fox]

>
>
> You have to understand that although the problem might seem trivial, fixes
> for problems like this can't break existing builds. That makes even the
> simplest fix challenging.
>

Not only that, it needs to cooperate with other functionality... just like
we found with the previous patch. It would work in some cases but it
couldn't function if the build.outputDirectory was changed. (or -f was used
for a different pom name).

Re: Progress on support for large projects

[Ralph Goers]

On May 15, 2009, at 1:10 PM, Joerg Hohwiller wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,


I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.


MNG-624 or maven-2.1.x-MNG-624 ?
I think it was maven-2.1.x-MNG-624. Its been a long time since I  
worked on this.






A big problem could be the encoding issue if you store XML in a  
string
and then want to save it with some Writer, you need to know the  
encoding

from the XML-header or you run into trouble.


My fix didn't store the XML in a string, it modified the DOM.


OK. But the existing parsing is done by XPP right?

I believe so.



Do we want parsing the POMs twice with different parsers?





Is there some general strategy decision about POM-transformation
design by the core developers of maven?
Maven 2.x is a mess with this. It is one of the things I believe they  
worked really hard to change in Maven 3. Again, I haven't reviewed the  
new code so I don't know how successful they were.



Do Brett and Jason care about this?
Everybody cares about this. The way Maven 2.x was implemented is very  
brittle. Almost every change made to the project builder ends up  
having nasty side effects.



Sorry for the stupid question, but your patch/branch seems to
be the second solution so this means to me that the first
has failed already. I now see that is was Eric Brown who
wasted his time already and he seemed somewhat disappointed.
As the problem of doing a POM-transformation
which is NOT only relevant for MNG-624 is quite general.
So I just want to avoid that the second approach will fail again.
I would not mind to invest some of my very little time as well
in this but only if there is a clear chance that we are going
towards a solution that fits well into the architecture of maven
and will therefore be accepted to be integrated in 2.1.x.


I seemed to be the only committer interested in fixing these issues. I  
did not like Eric's patch because it added logic the the artifact  
handler that it had no business knowing about.  As I recall I  
documented my reasons in one of the Jira issues.


You have to understand that although the problem might seem trivial,  
fixes for problems like this can't break existing builds. That makes  
even the simplest fix challenging.


Ralph


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

Re: Progress on support for large projects

[Brian Fox]

>
>
> Do you need simple IT-projects that I shall attach to MNG-4161 and related?
>

Sample ITs for sure, and some level of detail in a proposal like these:
http://docs.codehaus.org/display/MAVENUSER/User+Proposals

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi again,


>> Your better bet will be to try and get this documented so it can be
>> implemented in 3.x.

no change to see some improvement about version maintenance in 2.x?
See the list of issues I just posted and also look at the votes.

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

iEYEARECAAYFAkoN0zkACgkQmPuec2Dcv/+QagCgiQd4XEKgBWh4c98TkflW3Bek
2GcAnRdoBJSi3wWoLHEA6jJB3N8pvSAr
=l02j
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Brian,

> Your better bet will be to try and get this documented so it can be
> implemented in 3.x.

I would surely NOT mind. What do you expect?
A new xdoc? Or a diff to the actual source of
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Content somewhat like the level of detail in MNG-4161
but with nice examples?

Do you need simple IT-projects that I shall attach to MNG-4161 and related?

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

iEYEARECAAYFAkoN0p4ACgkQmPuec2Dcv/8TnwCfRZXQ8Wz1OOMwq4B8MXKanWyo
4qUAn0vYofuQCDUjS+PjOQ46VvgfpUUN
=GiG2
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Brian Fox]

On Fri, May 15, 2009 at 4:10 PM, Joerg Hohwiller wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> > I think you are referring to one of the other patches that was
> > submitted, not what I committed to the MNG-624 branch.
>
> MNG-624 or maven-2.1.x-MNG-624 ?
>
> >>
> >>
> >> A big problem could be the encoding issue if you store XML in a string
> >> and then want to save it with some Writer, you need to know the encoding
> >> from the XML-header or you run into trouble.
> >
> > My fix didn't store the XML in a string, it modified the DOM.
>
> OK. But the existing parsing is done by XPP right?
>
> Do we want parsing the POMs twice with different parsers?
>
> Is there some general strategy decision about POM-transformation
> design by the core developers of maven?
>
> Do Brett and Jason care about this?
>
> Sorry for the stupid question, but your patch/branch seems to
> be the second solution so this means to me that the first
> has failed already. I now see that is was Eric Brown who
> wasted his time already and he seemed somewhat disappointed.
> As the problem of doing a POM-transformation
> which is NOT only relevant for MNG-624 is quite general.
> So I just want to avoid that the second approach will fail again.
> I would not mind to invest some of my very little time as well
> in this but only if there is a clear chance that we are going
> towards a solution that fits well into the architecture of maven
> and will therefore be accepted to be integrated in 2.1.x.
>

Your better bet will be to try and get this documented so it can be
implemented in 3.x.

>
> >
> > Ralph
>
> Regards
>  Jörg
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoNzB8ACgkQmPuec2Dcv/8d0wCfcKw58DuETsqdU8vZfHPJEZ66
> vXIAn3QzreDl/1scgqpAPlDMu62OP4Ku
> =xUpi
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

> I think you are referring to one of the other patches that was
> submitted, not what I committed to the MNG-624 branch.

MNG-624 or maven-2.1.x-MNG-624 ?

>>
>>
>> A big problem could be the encoding issue if you store XML in a string
>> and then want to save it with some Writer, you need to know the encoding
>> from the XML-header or you run into trouble.
> 
> My fix didn't store the XML in a string, it modified the DOM.

OK. But the existing parsing is done by XPP right?

Do we want parsing the POMs twice with different parsers?

Is there some general strategy decision about POM-transformation
design by the core developers of maven?

Do Brett and Jason care about this?

Sorry for the stupid question, but your patch/branch seems to
be the second solution so this means to me that the first
has failed already. I now see that is was Eric Brown who
wasted his time already and he seemed somewhat disappointed.
As the problem of doing a POM-transformation
which is NOT only relevant for MNG-624 is quite general.
So I just want to avoid that the second approach will fail again.
I would not mind to invest some of my very little time as well
in this but only if there is a clear chance that we are going
towards a solution that fits well into the architecture of maven
and will therefore be accepted to be integrated in 2.1.x.

> 
> Ralph

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

iEYEARECAAYFAkoNzB8ACgkQmPuec2Dcv/8d0wCfcKw58DuETsqdU8vZfHPJEZ66
vXIAn3QzreDl/1scgqpAPlDMu62OP4Ku
=xUpi
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> 
> Off topic.
> 
> Actually I believe this isn't true anymore.
> 
> See http://jira.codehaus.org/browse/MECLIPSE-344
> "all dependent artefacts that are available in your eclipse-workspace
> will be attached as project references even if they are not in the
> reactor."
> It was fixed in 2.5
> 
> Can you try it on your project structure and confirm?
> 
> I know it works for me.
> 
> I have this structure
> 
> common projects
> - module cA
> ...
> - module cZ
> 
> My project
> - module pA
> ...
> - module pZ
> (where some of these projects depend upon projects from commons)
> 
> mvn eclipse:eclipse will make sure my module pA references the eclipse
> project for module cA (and not the jar of cA in the repo)

Thanks for the hint!
But only works if eclipse-plugin knows where my workspace is.
The location may be different for each developer so I can NOT
truly automate. Anyhow I will start using this.
At least better solution than what I had before.

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

iEYEARECAAYFAkoNxrQACgkQmPuec2Dcv/8VrQCdGu/eWpZnifkPYdW/u+6RqsKx
+eMAnRv5/EHXo0895onKGsmExxxtoC70
=gj/Z
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Stephen,

> 
> If A(1.0) has root(1.2-SNAPSHOT) as a parent it should never have been
> released as the pom for A(1.0) is based on content from root(1.2-SNAPSHOT)
> which is subject to change... which means that a released pom does not have
> a definitive content... bad karma

I agree and cant speak for Ralph, but I do NOT change versions (or anything
else that is relevant for deploying) of container-modules at all.
Why should I release a new version of my parent POMs if just some leave changed
or even if some internal site-report-setting changed. People that want to
use my deployed artifacts do NOT care about such changes. But in my case
every developer always checks out the entire head (or tag/branch) of SCM.
So there are different aspects of a deployed POM. If you ask me, all stuff
like , , , , etc.
is nuts for deployed POMs. But others may have a different view of the world.

But this might be the point where we do not get together with relase-plugin.
We simply have to accept that maven gives us flexibility to do things different
ways and release-plugin maybe can NOT address all of these ways and thats
just OK.

> 
> -Stephen
> 

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

iEYEARECAAYFAkoNxdIACgkQmPuec2Dcv/8SEgCgl/9Hnv5vfFAaRpz3noNdZuW1
x/IAn0AOXx3MSnC9xWvWFZKrZURU7OcR
=aIQF
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Brian Fox]

On Fri, May 15, 2009 at 2:58 PM, Joerg Hohwiller wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
>
> > By inheriting the version, groupId, etc. from the parent - yes. The
> > release plugin still handles the pom transformations and the tagging
> > (SCM URLs, snapshot to release version, release to next snapshot
> > version, etc.)
>
> But there is nothing to change in the POM if the version is a variable.
> Maven will (as suggested in this thread - or also in my usecase via
> xslt-plugin) replace the variable when installing. All I need to change
> is one variable (e.g. in settings.xml). I do not need a releas-plugin
> for that but others may want to.
>
> >
> >  I am also doing this in some other project that way and
> >> it works fine. But in my personal open-source project I have some
> >> core-libs that are used throughout the project and many modules that
> >> are piled up with lots of dependencies. I have some modules that
> >> are quite steady and do not change so I dont want to release a new
> >> version just because something else changed.
> >
> > I would try splitting those steady modules from the rest of the
> > structure since they seem to not share a common development/release
> > cycle. I would even consider moving these to another svn repository.
> > Without a real example to analyze, hard to tell.
>
> Once again: the release-plugin guys think in a specific way and there
> are others that have a different oppinion. For me the architecture
> of the system is the main criteria for structuring my pom-tree.
> Imagine that everybody makes it the way you describe because of
> release-plugin. The other day another cool plugin arises that forces
> you to structure your poms and scm by some other criteria.
> What if you want both plugins?
>

I wouldn't say it's the release plugin that dictates the layout, its what
makes sense in the scm. Generally you take a tree of things and tag it and
release it.


>
> I think it is a bad idea that a plugin gives a philosophy about
> how users should structure their project.
>
> Regards
>  Jörg
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6
> pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F
> =HnyW
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,


> By inheriting the version, groupId, etc. from the parent - yes. The
> release plugin still handles the pom transformations and the tagging
> (SCM URLs, snapshot to release version, release to next snapshot
> version, etc.)

But there is nothing to change in the POM if the version is a variable.
Maven will (as suggested in this thread - or also in my usecase via
xslt-plugin) replace the variable when installing. All I need to change
is one variable (e.g. in settings.xml). I do not need a releas-plugin
for that but others may want to.

> 
>  I am also doing this in some other project that way and
>> it works fine. But in my personal open-source project I have some
>> core-libs that are used throughout the project and many modules that
>> are piled up with lots of dependencies. I have some modules that
>> are quite steady and do not change so I dont want to release a new
>> version just because something else changed.
> 
> I would try splitting those steady modules from the rest of the
> structure since they seem to not share a common development/release
> cycle. I would even consider moving these to another svn repository.
> Without a real example to analyze, hard to tell.

Once again: the release-plugin guys think in a specific way and there
are others that have a different oppinion. For me the architecture
of the system is the main criteria for structuring my pom-tree.
Imagine that everybody makes it the way you describe because of
release-plugin. The other day another cool plugin arises that forces
you to structure your poms and scm by some other criteria.
What if you want both plugins?

I think it is a bad idea that a plugin gives a philosophy about
how users should structure their project.

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

iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6
pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F
=HnyW
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

>>
>> OK. So you would NOT mind if maven adds some new features that
>> are compatible to older versions of maven.
>> Thats all I am fighting for.
>>
> 
> No fighting required, just make a patch. If it's truly backwards compatible,
> then there wouldn't be much reason for it to be declined.
> 
> I'm interested in the use cases because during training I run into this a
> lot. Generally if you can move your process to one that works with Maven
> then it's not an issue. If you can't, well then it is. I've got ideas for
> how to make the release process better, but not enough time to tackle it
> now. Just updating the tools to support ASF policy is keeping me busy
> enough.
> 

I searched JIRA:
It was already requested in MNG-2576 so it seems the idea and usecase
is common and therefor good. The issue is closed/fixed but I could NOT
get it working...

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

iEYEARECAAYFAkoNub8ACgkQmPuec2Dcv//RVQCgiqgQEvovdbDo+LHWBxbzOebn
jUYAn0d4lIFFM1dTNa7A3dWeC1Q+OsgD
=9QN4
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Christian Schulte]

Ralph Goers schrieb:
>> They just shouldn't change things significantly without good  
>> arguments.
> 
> Which are only the ones you agree with?

I am really just trying to warn you about doing something dangerous.
Mixing release versions with snapshot versions. The release plugin takes
care of this - validation rules you want to bypass for whatever reason
you may have.

-- 
Christian


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

Re: Progress on support for large projects

[Stephen Connolly]

2009/5/15 Christian Schulte 

> Joerg Hohwiller schrieb:
> > Why? In SCM there should never be a non-snapshot module with snapshot
> > dependencies. Further a non-snapshot module should not be modified except
> > for pom.xml
>
> /trunk at revision 4
> +root(1.2-SNAPSHOT)
>  +A(1.0)
>  +B(1.3-SNAPSHOT)
>
> If the pom of A(1.0) inherits from root(1.2-SNAPSHOT) and
> root(1.2-SNAPSHOT) declares a dependency management with snapshot
> versions and A(1.0) declares a dependency without an explicit version,
> than A(1.0) may start depending on a snapshot. If you do 'mvn deploy' at
> root(1.2-SNAPSHOT) then A(1.0) will be deployed to the release
> repository, everything else to the snapshot repository.
>

If A(1.0) has root(1.2-SNAPSHOT) as a parent it should never have been
released as the pom for A(1.0) is based on content from root(1.2-SNAPSHOT)
which is subject to change... which means that a released pom does not have
a definitive content... bad karma

-Stephen

Re: Progress on support for large projects

[Ralph Goers]

On May 14, 2009, at 9:18 PM, Christian Schulte wrote:


Why? In SCM there should never be a non-snapshot module with snapshot
dependencies. Further a non-snapshot module should not be modified  
except

for pom.xml


/trunk at revision 4
+root(1.2-SNAPSHOT)
 +A(1.0)
 +B(1.3-SNAPSHOT)

If the pom of A(1.0) inherits from root(1.2-SNAPSHOT) and
root(1.2-SNAPSHOT) declares a dependency management with snapshot
versions and A(1.0) declares a dependency without an explicit version,
than A(1.0) may start depending on a snapshot. If you do 'mvn  
deploy' at

root(1.2-SNAPSHOT) then A(1.0) will be deployed to the release
repository, everything else to the snapshot repository.


Which is exactly why the deploy plugin should never redeploy something  
that is already in a release repository. It is ALWAYS wrong, even in a  
scenario where you rely on the release plugin to do its magic.  
Actually, in the case above since the parent pom is a SNAPSHOT the  
deploy should just ignore any modules that aren't snapshots.






OK. So you would NOT mind if maven adds some new features that
are compatible to older versions of maven.


They just shouldn't change things significantly without good  
arguments.


Which are only the ones you agree with?


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

Re: Progress on support for large projects

[Christian Schulte]

Joerg Hohwiller schrieb:
> Hi Christian,
> 
>> My question may have sounded rhetorically but I really meant that. You
>> could of course manage commit rights with subversion so that whenever
>> someone mistakenly would try to commit to that release version on trunk,
>> subversion could simply disallow that. So a developer would at least
>> have to ask someone for permission to do so. I just don't get the point
>> for what all this additional effort is good for. Really only to not
>> release artifacts whose code did not change ? As I see it, that only
>> introduces additional complexity without any advantage. 
> 
> I totally disagree. If your project is large and maybe offers
> components that will be used by others, you can get into
> version conflicts and will cause a lot of overhead in the repos.
> Anyways if you say it is just additional complexity and you should
> always release everything, then why do you have individual versions
> per module at all? 

If the parent is released every time just a single module is, _then_ I
suggest releasing all modules with that parent together.

Simply use one variable in every module and your
> process is so simple that there is no need for release-plugin anymore
> at all.

By inheriting the version, groupId, etc. from the parent - yes. The
release plugin still handles the pom transformations and the tagging
(SCM URLs, snapshot to release version, release to next snapshot
version, etc.)

 I am also doing this in some other project that way and
> it works fine. But in my personal open-source project I have some
> core-libs that are used throughout the project and many modules that
> are piled up with lots of dependencies. I have some modules that
> are quite steady and do not change so I dont want to release a new
> version just because something else changed.

I would try splitting those steady modules from the rest of the
structure since they seem to not share a common development/release
cycle. I would even consider moving these to another svn repository.
Without a real example to analyze, hard to tell.

> 
>> Indeed it
>> introduces some disadvantages every developer must be made aware of and
>> you cannot use quite well working maven tooling that way. Not because
>> this tooling behaves wrong, IMHO. The same applies to automatically
>> discovering the parent pom. That's constantly changing artifacts without
>> anyone noticing it, somehow. At least in all local repositories. It does
>> not matter if there are any code changes. Changing poms is the same as
>> changing code, IMHO. I would just say that it takes less than a week
>> until every developer has its own releases in the local repository and
>> noticing that is really not that easy. For me such setup would not work
>> at all since the CI server not only builds artifacts whenever someone
>> committed something, but forcibly runs builds every few days or so. So
>> for me that would just mean that the CI server would constantly deploy
>> differing release artifacts. Even worse, those release artifacts contain
>> a reference to a snapshot parent pom which introduces additional
>> problems. Non-reproducible.
> 
> Why? In SCM there should never be a non-snapshot module with snapshot
> dependencies. Further a non-snapshot module should not be modified except
> for pom.xml

/trunk at revision 4
+root(1.2-SNAPSHOT)
  +A(1.0)
  +B(1.3-SNAPSHOT)

If the pom of A(1.0) inherits from root(1.2-SNAPSHOT) and
root(1.2-SNAPSHOT) declares a dependency management with snapshot
versions and A(1.0) declares a dependency without an explicit version,
than A(1.0) may start depending on a snapshot. If you do 'mvn deploy' at
root(1.2-SNAPSHOT) then A(1.0) will be deployed to the release
repository, everything else to the snapshot repository.

> OK. So you would NOT mind if maven adds some new features that
> are compatible to older versions of maven.

They just shouldn't change things significantly without good arguments.

-- 
Christian


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

Re: Progress on support for large projects

[Barrie Treloar]

> Ask someone why you have to invoke eclipse:eclipse on toplevel everytime.
> If the dependency of some-module has changed, you can NOT invoke 
> eclipse:eclipse
> just on some-module since the plugin then wants to resolve the dependencies
> from the repository and adds JAR-Dependencies to the IDE project.

Off topic.

Actually I believe this isn't true anymore.

See http://jira.codehaus.org/browse/MECLIPSE-344
"all dependent artefacts that are available in your eclipse-workspace
will be attached as project references even if they are not in the
reactor."
It was fixed in 2.5

Can you try it on your project structure and confirm?

I know it works for me.

I have this structure

common projects
- module cA
...
- module cZ

My project
- module pA
...
- module pZ
(where some of these projects depend upon projects from commons)

mvn eclipse:eclipse will make sure my module pA references the eclipse
project for module cA (and not the jar of cA in the repo)

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

Re: Progress on support for large projects

[Brian Fox]

>
>
> OK. So you would NOT mind if maven adds some new features that
> are compatible to older versions of maven.
> Thats all I am fighting for.
>

No fighting required, just make a patch. If it's truly backwards compatible,
then there wouldn't be much reason for it to be declined.

I'm interested in the use cases because during training I run into this a
lot. Generally if you can move your process to one that works with Maven
then it's not an issue. If you can't, well then it is. I've got ideas for
how to make the release process better, but not enough time to tackle it
now. Just updating the tools to support ASF policy is keeping me busy
enough.

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Christian,

> 
> My question may have sounded rhetorically but I really meant that. You
> could of course manage commit rights with subversion so that whenever
> someone mistakenly would try to commit to that release version on trunk,
> subversion could simply disallow that. So a developer would at least
> have to ask someone for permission to do so. I just don't get the point
> for what all this additional effort is good for. Really only to not
> release artifacts whose code did not change ? As I see it, that only
> introduces additional complexity without any advantage. 

I totally disagree. If your project is large and maybe offers
components that will be used by others, you can get into
version conflicts and will cause a lot of overhead in the repos.
Anyways if you say it is just additional complexity and you should
always release everything, then why do you have individual versions
per module at all? Simply use one variable in every module and your
process is so simple that there is no need for release-plugin anymore
at all. I am also doing this in some other project that way and
it works fine. But in my personal open-source project I have some
core-libs that are used throughout the project and many modules that
are piled up with lots of dependencies. I have some modules that
are quite steady and do not change so I dont want to release a new
version just because something else changed.

> Indeed it
> introduces some disadvantages every developer must be made aware of and
> you cannot use quite well working maven tooling that way. Not because
> this tooling behaves wrong, IMHO. The same applies to automatically
> discovering the parent pom. That's constantly changing artifacts without
> anyone noticing it, somehow. At least in all local repositories. It does
> not matter if there are any code changes. Changing poms is the same as
> changing code, IMHO. I would just say that it takes less than a week
> until every developer has its own releases in the local repository and
> noticing that is really not that easy. For me such setup would not work
> at all since the CI server not only builds artifacts whenever someone
> committed something, but forcibly runs builds every few days or so. So
> for me that would just mean that the CI server would constantly deploy
> differing release artifacts. Even worse, those release artifacts contain
> a reference to a snapshot parent pom which introduces additional
> problems. Non-reproducible.

Why? In SCM there should never be a non-snapshot module with snapshot
dependencies. Further a non-snapshot module should not be modified except
for pom.xml

> 
> Don't get me wrong. I still think you have really good reasons for doing
>  things the way they are done. I just don't get it. I don't even see a
> single advantage but a lot of disadvantages. I am not saying that there
> may not be any advantages.
> 

OK. So you would NOT mind if maven adds some new features that
are compatible to older versions of maven.
Thats all I am fighting for.

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

iEYEARECAAYFAkoMkq4ACgkQmPuec2Dcv/9CxgCfXlKe4c7C0QtVPKY1kW4iUzQH
IZ0AoJA//ENI/jHk000ELe3oN73g5nyW
=zvjI
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Chistian,

> 
> What stops a developer from making changes to A(1.0) on trunk,
> rebuilding locally - that is - overwriting release artifacts with
> something different in the local repository, and then later on even
> commit those changes forgetting to increase the version to a snapshot ?
> Discipline ?
> 

Simply at a pre-commit hook that only allows to commit pom.xml in
some tree that has a non-snapshot version.

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

iEYEARECAAYFAkoMj8AACgkQmPuec2Dcv/+KugCgiacqSwnZayMjGJa8ZxT05Gtt
zJ8Ani67Nf5LSK8u9dww8XpDaFcSepN9
=kKR3
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Christian Schulte]

Ralph Goers schrieb:
> On May 13, 2009, at 5:09 PM, Christian Schulte wrote:
> 
>> Ralph Goers schrieb:
>>> So the tree really looks like:
>>>
>>> +tags
>>>   +root-1.0 (trunk revision 1)
>>> +A(1.0)
>>> +B(1.0)
>>>   +root-1.1 (trunk revision 2)
>>> +A(1.0)
>>> +B(1.1)
>>>   +root-1.2 (trunk revision 3)
>>> +A(1.0)
>>> +B(1.2)
>>> /trunk at revision 4
>>>   +root(1.2-SNAPSHOT)
>>> +A(1.0)
>>> +B(1.3-SNAPSHOT)
>>>
>>> This assumes that A has not been modified since its initial release
>>> and B is currently under development and has not been released.
>>>
>> What stops a developer from making changes to A(1.0) on trunk,
>> rebuilding locally - that is - overwriting release artifacts with
>> something different in the local repository, and then later on even
>> commit those changes forgetting to increase the version to a  
>> snapshot ?
>> Discipline ?
>>
> 
> Actually, this isn't at all the way we do releases. This was my  
> response to David's hypothetical scenario which didn't make any sense  
> to me. All I did was clean it up.
> 
> What we actually do looks more like:
> 
> +tags
>+library-1.0.0 (on branch-library-1.0) pom version is 1.0.0
>  +A(1.0.0)
>  +B(1.0.0)
>  +C(1.0.0)
>+library-1.0.1 (on branch-library-1.0) pom version is 1.0.1
>  +A(1.0.0)
>  +B(1.0.1)
>  +C(1.0.0)
>+library-1.1.0 (on branch-library-1.1) pom version is 1.1.0
>  +A(1.0.0)
>  +B(1.1.0)
>  +C(1.1.0)
> +branches
>+branch-library-1.0 (pom is still 1.0.1 - no work in progress on  
> branch)
>  +A(1.0.0)
>  +B(1.0.0)
>  +C(1.0.0)
>+branch-library-1.1 (pom is 1.1.0-SNAPSHOT) (work in progress)
>  +A(1.0.0)
>  +B(1.1.0)
>  +C(1.1.1-SNAPSHOT)
> /trunk (library-1.2-SNAPSHOT) (Work in progress)
>+A(1.1.0-SNAPSHOT) (new work)
>+B(1.1.0)
>+C(1.2.0-SNAPSHOT) (work from branch-library-1.1 has been merged)
> 
> The point here is not to debate the "right" or "wrong" way to manage  
> projects. It is what it is and it accomplishes our goals. The issue is  
> that the release plugin (at least the last time I reviewed it)  
> mandates that there is only one right way to do a release. As the  
> debate on Legal discuss last week shows this isn't necessarily the  
> case. I would suggest that the release plugin almost needs a lifecycle  
> of its own where the actual work is accomplished through plugins. If  
> things have changed significantly let me know and I'd be happy to look  
> at it again.
> 
> Ralph
>   

Some developers of the release-manager can better answer this. The
release manager uses its own phases internally, I think.



Hooking something in there may already be possible easily but I don't
know for sure.

My question may have sounded rhetorically but I really meant that. You
could of course manage commit rights with subversion so that whenever
someone mistakenly would try to commit to that release version on trunk,
subversion could simply disallow that. So a developer would at least
have to ask someone for permission to do so. I just don't get the point
for what all this additional effort is good for. Really only to not
release artifacts whose code did not change ? As I see it, that only
introduces additional complexity without any advantage. Indeed it
introduces some disadvantages every developer must be made aware of and
you cannot use quite well working maven tooling that way. Not because
this tooling behaves wrong, IMHO. The same applies to automatically
discovering the parent pom. That's constantly changing artifacts without
anyone noticing it, somehow. At least in all local repositories. It does
not matter if there are any code changes. Changing poms is the same as
changing code, IMHO. I would just say that it takes less than a week
until every developer has its own releases in the local repository and
noticing that is really not that easy. For me such setup would not work
at all since the CI server not only builds artifacts whenever someone
committed something, but forcibly runs builds every few days or so. So
for me that would just mean that the CI server would constantly deploy
differing release artifacts. Even worse, those release artifacts contain
a reference to a snapshot parent pom which introduces additional
problems. Non-reproducible.

Don't get me wrong. I still think you have really good reasons for doing
 things the way they are done. I just don't get it. I don't even see a
single advantage but a lot of disadvantages. I am not saying that there
may not be any advantages.

-- 
Christian

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

Re: Progress on support for large projects

[Ralph Goers]

On May 13, 2009, at 5:09 PM, Christian Schulte wrote:


Ralph Goers schrieb:

So the tree really looks like:

+tags
  +root-1.0 (trunk revision 1)
+A(1.0)
+B(1.0)
  +root-1.1 (trunk revision 2)
+A(1.0)
+B(1.1)
  +root-1.2 (trunk revision 3)
+A(1.0)
+B(1.2)
/trunk at revision 4
  +root(1.2-SNAPSHOT)
+A(1.0)
+B(1.3-SNAPSHOT)

This assumes that A has not been modified since its initial release
and B is currently under development and has not been released.



What stops a developer from making changes to A(1.0) on trunk,
rebuilding locally - that is - overwriting release artifacts with
something different in the local repository, and then later on even
commit those changes forgetting to increase the version to a  
snapshot ?

Discipline ?



Actually, this isn't at all the way we do releases. This was my  
response to David's hypothetical scenario which didn't make any sense  
to me. All I did was clean it up.


What we actually do looks more like:

+tags
  +library-1.0.0 (on branch-library-1.0) pom version is 1.0.0
+A(1.0.0)
+B(1.0.0)
+C(1.0.0)
  +library-1.0.1 (on branch-library-1.0) pom version is 1.0.1
+A(1.0.0)
+B(1.0.1)
+C(1.0.0)
  +library-1.1.0 (on branch-library-1.1) pom version is 1.1.0
+A(1.0.0)
+B(1.1.0)
+C(1.1.0)
+branches
  +branch-library-1.0 (pom is still 1.0.1 - no work in progress on  
branch)

+A(1.0.0)
+B(1.0.0)
+C(1.0.0)
  +branch-library-1.1 (pom is 1.1.0-SNAPSHOT) (work in progress)
+A(1.0.0)
+B(1.1.0)
+C(1.1.1-SNAPSHOT)
/trunk (library-1.2-SNAPSHOT) (Work in progress)
  +A(1.1.0-SNAPSHOT) (new work)
  +B(1.1.0)
  +C(1.2.0-SNAPSHOT) (work from branch-library-1.1 has been merged)

The point here is not to debate the "right" or "wrong" way to manage  
projects. It is what it is and it accomplishes our goals. The issue is  
that the release plugin (at least the last time I reviewed it)  
mandates that there is only one right way to do a release. As the  
debate on Legal discuss last week shows this isn't necessarily the  
case. I would suggest that the release plugin almost needs a lifecycle  
of its own where the actual work is accomplished through plugins. If  
things have changed significantly let me know and I'd be happy to look  
at it again.


Ralph
 


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

Re: Progress on support for large projects

[Christian Schulte]

Ralph Goers schrieb:
> So the tree really looks like:
> 
> +tags
>+root-1.0 (trunk revision 1)
>  +A(1.0)
>  +B(1.0)
>+root-1.1 (trunk revision 2)
>  +A(1.0)
>  +B(1.1)
>+root-1.2 (trunk revision 3)
>  +A(1.0)
>  +B(1.2)
> /trunk at revision 4
>+root(1.2-SNAPSHOT)
>  +A(1.0)
>  +B(1.3-SNAPSHOT)
> 
> This assumes that A has not been modified since its initial release  
> and B is currently under development and has not been released.
> 

What stops a developer from making changes to A(1.0) on trunk,
rebuilding locally - that is - overwriting release artifacts with
something different in the local repository, and then later on even
commit those changes forgetting to increase the version to a snapshot ?
Discipline ?

-- 
Christian

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

Re: Progress on support for large projects

[David Jencks]

On May 13, 2009, at 12:55 PM, Ralph Goers wrote:



On May 13, 2009, at 10:41 AM, David Jencks wrote:


Sorry I wasn't more specific last night at 2:00 am :-).  I need  
more scm context to understand.  I'm assuming something like svn with


+tags
+root-1.0 (1.0)
  +A(1.0)
  \B(1.0)
+root-1.1 (1.1)
  +A(1.0)
  \B(1.1)
\root-1.2 (1.1)
  +A(1.0)
  \B(1.2)
\trunk
\root(1.2-SNAPSHOT)
  +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???)
  \B(1.3-SNAPSHOT)

I have several assumptions about releasing stuff...


Your assumptions are not completely correct.
a) In our case a release is aways off a branch. This isn't  
particularly relevant to the discussion but it does make production  
maintenance easier so I'll ignore it.

b) tagging doesn't create a copy of anything.
Maybe on the svn server that's true, but I'd never know it from the  
client view I get by svn co, svn up, etc.


It just is a label that is a shortcut to a revision on a branch.  
Multiple tags that point to the same revision are not a problem and  
don't incur much overhead.


I really don't care how much trouble releasing stuff causes infra disc  
purchase procedures :-)



So the tree really looks like:

+tags
 +root-1.0 (trunk revision 1)
   +A(1.0)
   +B(1.0)
 +root-1.1 (trunk revision 2)
   +A(1.0)
   +B(1.1)
 +root-1.2 (trunk revision 3)
   +A(1.0)
   +B(1.2)
/trunk at revision 4
 +root(1.2-SNAPSHOT)
   +A(1.0)
   +B(1.3-SNAPSHOT)

This assumes that A has not been modified since its initial release  
and B is currently under development and has not been released.


So, we seem to have different views on acceptable ways to use svn.  If  
I was involved in such a project I would kick and scream until
- each release came from a single clearly identifiable scm location  
(violated by multiple tags for A(1.0), and the presence of A(1.0) in  
trunk)
- trunk contained only SNAPSHOT version (except possibly while someone  
is actually doing a release -- behavior of the release plugin I'm not  
thrilled with) (violated by A(1.0) in trunk).

or I gave up and forked it.

I could be completely misguided in this, but it's my current viewpoint.







- development will continue after the release
- therefore the version in "trunk" must be incremented so it's  
clear that snapshots are later than the release

- tags should not contain anything with a snapshot version
- releasing will create a tag of what's been released
- tagging for release creates a copy of an entire svn subtree, not  
a copy with stuff removed.
See above. While the tag applies to the whole subtree, no copy is  
made.


From the point of view of what you get on a client machine, I don't  
understand this.







I see several problems with the svn tree I sketched above:
- there are 3 or 4 copies of A claiming to be version 1.0
No. There are multiple tags that all point to the same subversion  
revision. This is not a problem.


Apparently we disagree on this.




- there is no plausible version for trunk/root/A
? If A has not been changed its version is still 1.0. If it has then  
it is 1.1-SNAPSHOT.

Again we disagree on whether this is acceptable.





- in tags, the version of root doesn't match the end of the  
directory name. (there are 2 version 1.1 roots)
Why would you allow a branch that matches a tag? If I was going to  
allow a branch to be created named root-1.2 then I would require  
that all tags be named root-1.2.n. If I did that then I would have


+tags
 +root-1.0.0 (trunk revision 1)
   +A(1.0.0)
   +B(1.0.0)
 +root-1.1.0 (trunk revision 2)
   +A(1.0.0)
   +B(1.1.0)
 +root-1.2.0 (root-1.2 revision 3)
   +A(1.0.0)
   +B(1.2.0)
/root-1.0 (branched from trunk at revision 1)
 +A(1.0.0)
 +B(1.0.0)
/root-1.1 (branched from trunk at revision 2)
 +A(1.0.0)
 +B(1.1.0)
/root-1.2 (branched from trunk at revision 3)
 +A(1.0.0)
 +B(1.2.0)
/trunk at revision 4
 +root(1.2-SNAPSHOT)
   +A(1.0)
   +B(1.3-SNAPSHOT)



I must not be understanding something basic about what you are  
proposing I'm probably beating a long-dead horse but could you  
please be even more specific about what scm operations you want to  
have as part of a release and what the scm repo looks like  
afterwards?
I'm not proposing anything. I'm just explaining what this particular  
project has been doing for the last 5 years and why Maven 2 is a  
PITA in this regard. Maven 1 was actually easier for this particular  
project.


This process may work fine for the project in question and you in  
other circumstances, but would keep me from contributing no matter  
what build tool was in use.


Here, the release plugin seems to me to strongly promote good scm  
practices.  The only think I'd like to see is, given a setup like


trunk (has no pom)
  +parent-pom
  +P1
  +P2

  +P1000

an easy way to release all the, say,  odd numbered projects at once  
rather than running the release plugin on each one independently.


Anyway, I really appreciate your taking the time to explain your point  
of view to me.  While I cu

Re: Progress on support for large projects

[Ralph Goers]

On May 13, 2009, at 12:33 PM, Joerg Hohwiller wrote:


Okay. So thats what I guessed when I said that the MavenProject/ 
Model is
just a stupid POJO and various plugins manipulate it with side  
effects.
Sounds a little hacky to me but thats the way it is. So my  
serialization

idea is nuts though.

Anyhow I think that if you have some information in memory, you should
NOT have to write it to the disc so that someone else can copy (read  
and write)
it again. I thought that you store the transformed XML in that new  
string

attribute (was it alternativeRepresentation) so the Installer/Deployer
could write this string if available instead of copying the pom.xml  
as is.


I think you are referring to one of the other patches that was  
submitted, not what I committed to the MNG-624 branch.



A big problem could be the encoding issue if you store XML in a string
and then want to save it with some Writer, you need to know the  
encoding

from the XML-header or you run into trouble.


My fix didn't store the XML in a string, it modified the DOM.

Ralph

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

Re: Progress on support for large projects

[Ralph Goers]

On May 13, 2009, at 10:41 AM, David Jencks wrote:


Sorry I wasn't more specific last night at 2:00 am :-).  I need more  
scm context to understand.  I'm assuming something like svn with


+tags
 +root-1.0 (1.0)
   +A(1.0)
   \B(1.0)
 +root-1.1 (1.1)
   +A(1.0)
   \B(1.1)
 \root-1.2 (1.1)
   +A(1.0)
   \B(1.2)
\trunk
 \root(1.2-SNAPSHOT)
   +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???)
   \B(1.3-SNAPSHOT)

I have several assumptions about releasing stuff...


Your assumptions are not completely correct.
a) In our case a release is aways off a branch. This isn't  
particularly relevant to the discussion but it does make production  
maintenance easier so I'll ignore it.
b) tagging doesn't create a copy of anything. It just is a label that  
is a shortcut to a revision on a branch. Multiple tags that point to  
the same revision are not a problem and don't incur much overhead.


So the tree really looks like:

+tags
  +root-1.0 (trunk revision 1)
+A(1.0)
+B(1.0)
  +root-1.1 (trunk revision 2)
+A(1.0)
+B(1.1)
  +root-1.2 (trunk revision 3)
+A(1.0)
+B(1.2)
/trunk at revision 4
  +root(1.2-SNAPSHOT)
+A(1.0)
+B(1.3-SNAPSHOT)

This assumes that A has not been modified since its initial release  
and B is currently under development and has not been released.





- development will continue after the release
- therefore the version in "trunk" must be incremented so it's clear  
that snapshots are later than the release

- tags should not contain anything with a snapshot version
- releasing will create a tag of what's been released
- tagging for release creates a copy of an entire svn subtree, not a  
copy with stuff removed.

See above. While the tag applies to the whole subtree, no copy is made.



I see several problems with the svn tree I sketched above:
- there are 3 or 4 copies of A claiming to be version 1.0
No. There are multiple tags that all point to the same subversion  
revision. This is not a problem.


- there is no plausible version for trunk/root/A
? If A has not been changed its version is still 1.0. If it has then  
it is 1.1-SNAPSHOT.


- in tags, the version of root doesn't match the end of the  
directory name. (there are 2 version 1.1 roots)
Why would you allow a branch that matches a tag? If I was going to  
allow a branch to be created named root-1.2 then I would require that  
all tags be named root-1.2.n. If I did that then I would have


+tags
  +root-1.0.0 (trunk revision 1)
+A(1.0.0)
+B(1.0.0)
  +root-1.1.0 (trunk revision 2)
+A(1.0.0)
+B(1.1.0)
  +root-1.2.0 (root-1.2 revision 3)
+A(1.0.0)
+B(1.2.0)
/root-1.0 (branched from trunk at revision 1)
  +A(1.0.0)
  +B(1.0.0)
/root-1.1 (branched from trunk at revision 2)
  +A(1.0.0)
  +B(1.1.0)
/root-1.2 (branched from trunk at revision 3)
  +A(1.0.0)
  +B(1.2.0)
/trunk at revision 4
  +root(1.2-SNAPSHOT)
+A(1.0)
+B(1.3-SNAPSHOT)



I must not be understanding something basic about what you are  
proposing I'm probably beating a long-dead horse but could you  
please be even more specific about what scm operations you want to  
have as part of a release and what the scm repo looks like afterwards?
I'm not proposing anything. I'm just explaining what this particular  
project has been doing for the last 5 years and why Maven 2 is a PITA  
in this regard. Maven 1 was actually easier for this particular project.


Ralph


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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ralph,

> 
> I've been "promised" by Jason that the work on Maven 3 is going to fix
> some of these issues. I simply haven't had the time to look at the work
> on Maven 3 and even if I had, it has been changing at a fairly rapid
> pace for months.
> 
> While, in principal, Maven's processing is pretty simple - it just
> collects artifacts and runs plugins - the reality is that there are lots
> of side effects and timing issues.

OK.

> 
> The fix needed to address 2 things; determining the parent pom version
> and resolving variables so that when the pom is deployed to the
> repository the pom isn't ambiguous. That does not include resolving
> variables in dependencies because those are actually OK to not be locked
> down in the repo.  Unfortunately, once the pom is processed it is
> impossible to use the Maven Model object to create a new pom. It
> contains lots of information that wasn't in the original pom that
> shouldn't be in the pom deployed to a repository.  The fix I did took
> care of this effectively. Writing it to an alternate directory and then
> telling maven where it was meant that the artifact deployer didn't need
> any changes at all.

Okay. So thats what I guessed when I said that the MavenProject/Model is
just a stupid POJO and various plugins manipulate it with side effects.
Sounds a little hacky to me but thats the way it is. So my serialization
idea is nuts though.

Anyhow I think that if you have some information in memory, you should
NOT have to write it to the disc so that someone else can copy (read and write)
it again. I thought that you store the transformed XML in that new string
attribute (was it alternativeRepresentation) so the Installer/Deployer
could write this string if available instead of copying the pom.xml as is.

A big problem could be the encoding issue if you store XML in a string
and then want to save it with some Writer, you need to know the encoding
from the XML-header or you run into trouble.

> 
> Ralph

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

iEYEARECAAYFAkoLIHwACgkQmPuec2Dcv//OawCfTCpa29oxzE68SoadDl2pYOC2
uAsAn1/+M2rOHg+UlrklPJRabJD7oK6s
=YnIP
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Milos,

> 
>> mvn eclipse:eclipse does perform a build (partially) and might even produce
>> 1 eclipse project for multiple maven projects (correct me if I'm wrong)

No it does not. But I hope it will one finest day.
And it will definitely do NOT compile or invoke tests.
All it does is invoking phases for code-generation.

> 
>> In NetBeans (IDE I use and develop maven integration for) no build is
>> performed and we rely entirely on maven metadata when it comes to project
>> representation. Doing a build is out of questions, opening of projects would
>> be too slow. And it's a perfectly sound to assume that one wants to open
>> just a single maven project from apache geronimo codebase without actually
>> building the 200+ multiproject.

I am absolutely with you that you do NOT want to build entire geronimo
if just one module changes. What I was thinking about is that
if "mvn somegoal" is invoked in module some-module maven scans the pom.xml
of some-module. Currently it resolves all parents up to toplevel starting from
some-module. What it does NOT do is to go down from toplevel and scan (NOT
build!) recursively the entire project tree so all modules are available
to maven's internals (that what I named the reactor) but that does NOT mean,
that the goal is invoked on all of the modules but still only on some-module.
But now the invoked plugins could resolve what other-module in the tree is
about. I was suggesting to have this feature disabled by default but have
a command-line option to enable this.
Ask someone why you have to invoke eclipse:eclipse on toplevel everytime.
If the dependency of some-module has changed, you can NOT invoke eclipse:eclipse
just on some-module since the plugin then wants to resolve the dependencies
from the repository and adds JAR-Dependencies to the IDE project.
Further ask someone why you can not build some-module if it depends on
other-module but thats not already installed. It can be on the local disc
and the knowledge how to build some-module is available to maven but it
is simply too stupid to do it. You have to go and invoke install on other-module
yourself and then on some-module afterwards. Now try to explain this to somebody
new to maven. Next there might be some tests that fail in other-module so you
cant install it but still want to build some-module.

>> Even with brutal performance hacks the 200 projects take about 10 minutes to
>> open, while the single project is just a snap.

Surely.

> 
>> I'm not sure what the "auto-reactor" feature in eclipse does, 

Maybe my post was missleading, but I was talking about a vision
not about what already works.

> but in general
>> and especially for large projects it's hard to figure automatically what the
>> "reactor" is.. is it just the geronomo plugins pom, or we need all of
>> geronimo, or just geronimo aspectj plugin parent? if you are the geronimo
>> dev you might know, but will everyone figure that out?

Well let me say so. I am suggesting a new feature to maven that is 100% downward
compatible. Nobody has to use it if he does NOT like it. But it would solve the
problems of many users and make maven even better.

> 
>> Milos

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

iEYEARECAAYFAkoLHgoACgkQmPuec2Dcv/+L0gCZAfkMoCLgf8608h4vKxmGka7C
F0MAnRoehAtfciJHGFSFdyQLDI/cWCyi
=CpO/
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi David,

> [cut.]
> 
> Sorry I wasn't more specific last night at 2:00 am :-).  I need more scm
> context to understand.  I'm assuming something like svn with
> 
> +tags
>   +root-1.0 (1.0)
> +A(1.0)
> \B(1.0)
>   +root-1.1 (1.1)
> +A(1.0)
> \B(1.1)
>   \root-1.2 (1.1)
> +A(1.0)
> \B(1.2)
> \trunk
>   \root(1.2-SNAPSHOT)
> +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???)
> \B(1.3-SNAPSHOT)
> 
> I have several assumptions about releasing stuff...
> 
> - development will continue after the release
> - therefore the version in "trunk" must be incremented so it's clear
> that snapshots are later than the release
> - tags should not contain anything with a snapshot version
> - releasing will create a tag of what's been released
> - tagging for release creates a copy of an entire svn subtree, not a
> copy with stuff removed.
> 
> I see several problems with the svn tree I sketched above:
> - there are 3 or 4 copies of A claiming to be version 1.0
> - there is no plausible version for trunk/root/A
> - in tags, the version of root doesn't match the end of the directory
> name. (there are 2 version 1.1 roots)
> 
> I must not be understanding something basic about what you are
> proposing I'm probably beating a long-dead horse but could you
> please be even more specific about what scm operations you want to have
> as part of a release and what the scm repo looks like afterwards?

Like Ralph, I have no problem with my scm (which is indeed svn).
I also want to maintain versions of modules and have the problems
that when I change a version I typically have to change this
in all other POMs pointing to the module that changed version.
Besiders there can be excuses where a dependency version remains
unchanged, so no automatism that release-plugin could guess.
And I want to keep modules unchanged in the tree. In my case they would
NOT have to be rebuild but that does NOT matter to me.
Maintaining these redundant versions is hell if you do it by hand.
I have some hacky tools but it could be so easy if you could just
omit the version in the dependencies of my local pom.xml's.

To answer the SCM-structure question:
There maybe some good conventions but SVN gives you a lot of flexibility
in whatever you do. I personally always have a flat list of all my modules
in tags and then have the according module copied (tagged) there named by
its version. I never think that release-plugin has to deal with all
possible ways that users can do their release-management. It has to go
some way and there will always be people that want it different so I
think the release-plugin is NOT the magic answer to all of our problems.

> 
> thanks
> david jencks

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

iEYEARECAAYFAkoLGWUACgkQmPuec2Dcv/9MggCbBGoMTwZOct1/WiOBUjPmUoxa
SQYAn2+uQ6MPAWWSSuUPyX9oK0wtr9hV
=YdFZ
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[David Jencks]

On May 13, 2009, at 7:02 AM, Ralph Goers wrote:



On May 13, 2009, at 12:53 AM, David Jencks wrote:



I'm even more mystified and understand how you want to use scm even  
less.  One of the basic principles I have for scm is that stuff  
shouldn't be duplicated, in the sense that if some artifact is  
released at version 1.2.3.4 say, the scm location for that release  
can be found in only one, unique, place in the scm tree, such as an  
svn tag.


Now if I understand what you are proposing, its to have
+root(1.2-SNAPSHOT)
+A(1.1-SNAPSHOT)
+B(1.3-SNAPSHOT)

Only B has changed since the last release, which was of root (1.1),  
A(1.1) and B(1.2); these are the version in the release tag.


If B is the only thing that has changed then you would have:
+root(1.2-SNAPSHOT)
 +A(1.0)
 +B(1.3-SNAPSHOT)

In this case two artifacts would be deployed during the release:
1. The library bom pom (which, in this case, is the pom in root) for  
version 1.2.

2. The artifact for B 1.3

A 1.0 is part of the tag, is built and tested during the build, but  
is not redeployed to the repository. After the release the scm will  
contain:

+root(1.2)
 +A(1.0)
 +B(1.3)



Sorry I wasn't more specific last night at 2:00 am :-).  I need more  
scm context to understand.  I'm assuming something like svn with


+tags
  +root-1.0 (1.0)
+A(1.0)
\B(1.0)
  +root-1.1 (1.1)
+A(1.0)
\B(1.1)
  \root-1.2 (1.1)
+A(1.0)
\B(1.2)
\trunk
  \root(1.2-SNAPSHOT)
+A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???)
\B(1.3-SNAPSHOT)

I have several assumptions about releasing stuff...

- development will continue after the release
- therefore the version in "trunk" must be incremented so it's clear  
that snapshots are later than the release

- tags should not contain anything with a snapshot version
- releasing will create a tag of what's been released
- tagging for release creates a copy of an entire svn subtree, not a  
copy with stuff removed.


I see several problems with the svn tree I sketched above:
- there are 3 or 4 copies of A claiming to be version 1.0
- there is no plausible version for trunk/root/A
- in tags, the version of root doesn't match the end of the directory  
name. (there are 2 version 1.1 roots)


I must not be understanding something basic about what you are  
proposing I'm probably beating a long-dead horse but could you  
please be even more specific about what scm operations you want to  
have as part of a release and what the scm repo looks like afterwards?


thanks
david jencks





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




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

Re: Progress on support for large projects

[Ralph Goers]

On May 13, 2009, at 12:53 AM, David Jencks wrote:



I'm even more mystified and understand how you want to use scm even  
less.  One of the basic principles I have for scm is that stuff  
shouldn't be duplicated, in the sense that if some artifact is  
released at version 1.2.3.4 say, the scm location for that release  
can be found in only one, unique, place in the scm tree, such as an  
svn tag.


Now if I understand what you are proposing, its to have
+root(1.2-SNAPSHOT)
 +A(1.1-SNAPSHOT)
 +B(1.3-SNAPSHOT)

Only B has changed since the last release, which was of root (1.1),  
A(1.1) and B(1.2); these are the version in the release tag.


If B is the only thing that has changed then you would have:
+root(1.2-SNAPSHOT)
  +A(1.0)
  +B(1.3-SNAPSHOT)

In this case two artifacts would be deployed during the release:
1. The library bom pom (which, in this case, is the pom in root) for  
version 1.2.

2. The artifact for B 1.3

A 1.0 is part of the tag, is built and tested during the build, but is  
not redeployed to the repository. After the release the scm will  
contain:

+root(1.2)
  +A(1.0)
  +B(1.3)



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

Re: Progress on support for large projects

[David Jencks]

On May 12, 2009, at 7:02 PM, Ralph Goers wrote:



On May 12, 2009, at 6:20 PM, David Jencks wrote:



On May 12, 2009, at 3:43 PM, Ralph Goers wrote:



On May 12, 2009, at 2:43 PM, Brian Fox wrote:





As I already said, I talked about release-plugin and my view of  
the world
and it seems NOT to fit together. My POM-tree follows strict  
logical
aspects that is motivated by the architecture of the project and  
NOT by

the philosophy of some plugin.



I'm trying to understand your structure and motivations behind  
it, so if you
would care to elaborate, we can be sure to consider these aspects  
down the

road.


Well, you've seen mine. Imagine Apache commons where you wanted to  
run a build from the root of commons. Not everything changes with  
each release so it is silly to deploy new jar versions that  
haven't changed. So you create a "bill of materials" (bom) pom  
that has the versions of all the subprojects and anything wanting  
to use a commons project can just import that and then specify  
dependencies on the various commons subprojects without specifying  
a version. But to build this all the subprojects need to have the  
bom pom as their parent or grandparent. Thus, any time you change  
the bom pom version every subproject has to change even if nothing  
changed in it. PITA.


Granted, my "library" isn't as big as commons, put it still  
currently contains 22 pom.xml files that have to be modified each  
time the bom pom changes.


I'm fairly mystified how what you and Jorg appear to want could  
work with any of the scm systems I know about, that tag an entire  
file system subtree at once.  Maybe I don't understand what you  
guys are talking about at all. here's what I think you want:


file system structure showing projects
+root
+A
+B
+C
...
+D


Probably Jorg has further nesting, but I don't think that actually  
affects the argument.


Projects A, C, E, G,... need to be released right now, whereas  
projects B, D, F... are just fine and don't need releases.


IIUC you guys are supposing a parent pom for all these projects in  
"root" and want to be able to run a release on root and have the  
effect be to release just A, C, E, G and the root pom.


No. The root represents the library. The release is of the library,  
not the individual subprojects. I just don't want new versions  
created for subprojects that didn't change.



So if you run a release on root the entire tree will get tagged  
including B, D, F etc that you didn't want tagged.


Actually, I do want them tagged. The "bill of materials" represents  
a release of the whole library. It is just that some of the  
artifacts in the library didn't change. But they should all be part  
of the release tag.



So I think what you want to do is have a quick way to run releases  
on A,C,E,G,... and have each of those tagged individually and not  
tag the whole tree at once.


No. See above.



My impression is that what you are fighting is the scm system, not  
maven.


No. The SCM isn't a problem. However, mvn deploy will try to deploy  
artifacts that haven't changed since the last release. That is bad.  
Nexus should be able to silently ignore those or the deployer should  
somehow be able to detect that the artifact shouldn't be deployed.


I'm even more mystified and understand how you want to use scm even  
less.  One of the basic principles I have for scm is that stuff  
shouldn't be duplicated, in the sense that if some artifact is  
released at version 1.2.3.4 say, the scm location for that release can  
be found in only one, unique, place in the scm tree, such as an svn tag.


Now if I understand what you are proposing, its to have
+root(1.2-SNAPSHOT)
  +A(1.1-SNAPSHOT)
  +B(1.3-SNAPSHOT)

Only B has changed since the last release, which was of root (1.1),  
A(1.1) and B(1.2); these are the version in the release tag.


So you tag this after arranging the new release versions.  You new tag  
has root(1.2), A(1.1) and B(1.3), and trunk has root(1.3-SNAPSHOT),  
A(1.1-SNAPSHOT) and B(1.4-SNAPSHOT)


The problem I have with this is that A(1.1) is present in two  
different tags, violating the uniqueness principle I hold to.


Have I yet again misunderstood the actions you want to take during  
release or do you think the uniqueness principle is not worth  
following?  If I've misunderstood again, could you provide a more  
concrete example with versions and contents of tags to help me  
understand?


thanks
david jencks




Ralph


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




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

Re: Progress on support for large projects

[Milos Kleint]

On Tue, May 12, 2009 at 11:01 PM, Joerg Hohwiller wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Milos,
> >
> > relying on the reactor and giving up on being able to build the one
> project
> > separately is very bad (read: completely breaks) any IDE integration.
>
> I totally disagree. I am successfully using maven-eclipse-plugin (mvn
> eclipse:eclipse) and this works perfectly with Eclipse except if you
> do a lot of filtering. The suggested approach would have no influence on
> my IDE, omitted versions would become inter-project-dependencies in eclipse
> and everything is fine.


mvn eclipse:eclipse does perform a build (partially) and might even produce
1 eclipse project for multiple maven projects (correct me if I'm wrong)

In NetBeans (IDE I use and develop maven integration for) no build is
performed and we rely entirely on maven metadata when it comes to project
representation. Doing a build is out of questions, opening of projects would
be too slow. And it's a perfectly sound to assume that one wants to open
just a single maven project from apache geronimo codebase without actually
building the 200+ multiproject.
Even with brutal performance hacks the 200 projects take about 10 minutes to
open, while the single project is just a snap.

I'm not sure what the "auto-reactor" feature in eclipse does, but in general
and especially for large projects it's hard to figure automatically what the
"reactor" is.. is it just the geronomo plugins pom, or we need all of
geronimo, or just geronimo aspectj plugin parent? if you are the geronimo
dev you might know, but will everyone figure that out?

Milos


>
> I tried m2eclipse and iam about 20 times and always gave up, because
> they were simply NOT able to run my project. E.g. I have source/target
> set to 1.5 for compiler-plugin but require 1.6 for development. m2eclipse
> thinks that it needs to replace 1.6 with 1.5 wenn I do m2 enable of my
> project.
>
> However if all the bugs of these plugins would be fixed, and the
> "auto-reactor" feature was working, everything could be fine as well
> together with the suggested feature. One day there will be eclipse 4.x
> and support multi-projects so the entire project (and its reactor)
> can be managed as a whole.
> I heard this already works for idea.
>
> >
> > Milos
> >
>
> Regards
>  Jörg
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoJ47EACgkQmPuec2Dcv//5iACfc1jnc4F33uoOKQ/JFKO8IUuP
> x5sAn2m0GO5n32Uz+r0C1Fa23x1PjXxx
> =zmBx
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Progress on support for large projects

[Christian Schulte]

Ralph Goers schrieb:
> On May 12, 2009, at 9:30 PM, Christian Schulte wrote:
> 
>> Ralph Goers schrieb:
>>> Imagine that you could get a pom.xml for all of Apache Commons that
>>> contained the dependency management for it. Every time a commons
>>> project released a new Commons "bill of materials" would go with it.
>>>
>>> a) You want all the projects to be part of the build to be sure that
>>> they all work together. Even though some projects didn't change,
>>> running the unit tests will help identify any compatibility problems.
>> If an artifact did not change, those tests will always yield the same
>> results as during the release of that artifact. By "did not change" I
>> assume that not only the source code did not change, also the pom and
>> everything else also did not change. Maven did not change, not a  
>> single
>> Maven plugin changed, no dependency, etc.
> 
> This assumption is incorrect. All the projects in the library use  
> other parts of the library, just as commons projects use other commons  
> projects. Because a project does not specify the version of the  
> project it depends on but obtains it from the bom pom the dependency  
> will change with the new release.

Ok. No code changes but the artifact and you don't want to release
without actual code changes.

-- 
Christian


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

Re: Progress on support for large projects

[Stephen Connolly]

It sounds like some people should have a look at the
versions-maven-plugin...

ok, so it will still force updating your pom, but it will allow releasing
individual modules using the release plugin and then updating the reactor to
reflect the new release.

-Stephen

Re: Progress on support for large projects

[Ralph Goers]

On May 12, 2009, at 9:30 PM, Christian Schulte wrote:


Ralph Goers schrieb:


Imagine that you could get a pom.xml for all of Apache Commons that
contained the dependency management for it. Every time a commons
project released a new Commons "bill of materials" would go with it.

a) You want all the projects to be part of the build to be sure that
they all work together. Even though some projects didn't change,
running the unit tests will help identify any compatibility problems.


If an artifact did not change, those tests will always yield the same
results as during the release of that artifact. By "did not change" I
assume that not only the source code did not change, also the pom and
everything else also did not change. Maven did not change, not a  
single

Maven plugin changed, no dependency, etc.


This assumption is incorrect. All the projects in the library use  
other parts of the library, just as commons projects use other commons  
projects. Because a project does not specify the version of the  
project it depends on but obtains it from the bom pom the dependency  
will change with the new release. Thus all subprojects must be tested.  
Because of this the rest of your response doesn't really apply.


Ralph


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

Re: Progress on support for large projects

[Christian Schulte]

Ralph Goers schrieb:
> 
> Imagine that you could get a pom.xml for all of Apache Commons that  
> contained the dependency management for it. Every time a commons  
> project released a new Commons "bill of materials" would go with it.
> 
> a) You want all the projects to be part of the build to be sure that  
> they all work together. Even though some projects didn't change,  
> running the unit tests will help identify any compatibility problems.

If an artifact did not change, those tests will always yield the same
results as during the release of that artifact. By "did not change" I
assume that not only the source code did not change, also the pom and
everything else also did not change. Maven did not change, not a single
Maven plugin changed, no dependency, etc. Constantly rebuilding a tag
without ever changing anything. If you want to ensure that some
artifacts work together, there is no need to rebuild them. Depending on
released artifacts suffices instead of rebuilding those tags over and
over again. If an artifact contains unit tests used to test that things
work together, that sounds like you are doing integration testing
instead of unit testing during the build. Creating an independent
artifact containing the integration tests and running those integration
tests independently helps a lot in such situations. Testing that
building those artifacts all together works is another story. That's
testing the build itself. I would say that's what the maven integration
tests are for.

> b) You don't want each release's bill of materials to only contain  
> what changed, it should reflect the whole library.

It does - except the modules element. If you do not change the release
versions of the artifacts you do not want to release, those just stay
the same with every new release of that bom. The modules element changes
with every release but that does not make any problems for the released
poms since that element is only used to aggregate modules during
building. The tag which gets created during the release cannot be used
to build all artifacts together. If that's what you want, there really
seems no other way to either edit the tagged pom after the release
re-adding all modules you did not release or release all those artifacts
together. That also means that even if no code changed for some of those
artifacts, the pom does which forces you to release with a different
version nevertheless. Even changing just the parent version produces a
new artifact version - that is - the jar file and the pom are tightly
coupled and there is no way to release just the pom without the jar.
Automatically resolving the parent seems quite dangerous if different
parent versions stop leading to different child versions.

> 
> A release consists of converting all subprojects marked as snapshots  
> to non-snapshots and leaving the other subprojects alone, tagging  
> everything, building everything and then deploying only the artifacts  
> that were modified to Nexus, along with the bom pom. Note - it does  
> not end with changing everything to snapshots. We only do that when we  
> actually change something.

I think I do get your point. What is still unclear is why you want to
constantly rebuild those tags. Even if its just for running those tests
during the build. Why should those test results ever change if nothing
else has changed ? So I assume there must be some kind of changes
somewhere so that rebuilding the whole library really makes sense. What
then does not make sense is to not use snapshot versions which would
make the release plugin work for you out of the box.

-- 
Christian


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

Re: Progress on support for large projects

[Ralph Goers]

On May 12, 2009, at 6:17 PM, Christian Schulte wrote:


Ralph Goers schrieb:

On May 12, 2009, at 2:43 PM, Brian Fox wrote:




As I already said, I talked about release-plugin and my view of the
world
and it seems NOT to fit together. My POM-tree follows strict  
logical

aspects that is motivated by the architecture of the project and
NOT by
the philosophy of some plugin.


I'm trying to understand your structure and motivations behind it,
so if you
would care to elaborate, we can be sure to consider these aspects
down the
road.


Well, you've seen mine. Imagine Apache commons where you wanted to  
run

a build from the root of commons. Not everything changes with each
release so it is silly to deploy new jar versions that haven't
changed.


Why not just remove the modules which haven't changed from the  
parent ?
The updated parent can still be imported afterwards just as you  
describe

and the release plugin could be updated to do this automatically as
well. Instead of failing whenever a non-snapshot version is  
encountered,

it could just remove that non-snapshot module element from the
corresponding parent and not touch that artifact's version anywhere
during release preparation. That's changing aggregation rules with  
every

release somehow, I admit.



Imagine that you could get a pom.xml for all of Apache Commons that  
contained the dependency management for it. Every time a commons  
project released a new Commons "bill of materials" would go with it.


a) You want all the projects to be part of the build to be sure that  
they all work together. Even though some projects didn't change,  
running the unit tests will help identify any compatibility problems.
b) You don't want each release's bill of materials to only contain  
what changed, it should reflect the whole library.


A release consists of converting all subprojects marked as snapshots  
to non-snapshots and leaving the other subprojects alone, tagging  
everything, building everything and then deploying only the artifacts  
that were modified to Nexus, along with the bom pom. Note - it does  
not end with changing everything to snapshots. We only do that when we  
actually change something.


Ralph



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

Re: Progress on support for large projects

[Ralph Goers]

On May 12, 2009, at 6:20 PM, David Jencks wrote:



On May 12, 2009, at 3:43 PM, Ralph Goers wrote:



On May 12, 2009, at 2:43 PM, Brian Fox wrote:





As I already said, I talked about release-plugin and my view of  
the world
and it seems NOT to fit together. My POM-tree follows strict  
logical
aspects that is motivated by the architecture of the project and  
NOT by

the philosophy of some plugin.



I'm trying to understand your structure and motivations behind it,  
so if you
would care to elaborate, we can be sure to consider these aspects  
down the

road.


Well, you've seen mine. Imagine Apache commons where you wanted to  
run a build from the root of commons. Not everything changes with  
each release so it is silly to deploy new jar versions that haven't  
changed. So you create a "bill of materials" (bom) pom that has the  
versions of all the subprojects and anything wanting to use a  
commons project can just import that and then specify dependencies  
on the various commons subprojects without specifying a version.  
But to build this all the subprojects need to have the bom pom as  
their parent or grandparent. Thus, any time you change the bom pom  
version every subproject has to change even if nothing changed in  
it. PITA.


Granted, my "library" isn't as big as commons, put it still  
currently contains 22 pom.xml files that have to be modified each  
time the bom pom changes.


I'm fairly mystified how what you and Jorg appear to want could work  
with any of the scm systems I know about, that tag an entire file  
system subtree at once.  Maybe I don't understand what you guys are  
talking about at all. here's what I think you want:


file system structure showing projects
+root
 +A
 +B
 +C
...
 +D


Probably Jorg has further nesting, but I don't think that actually  
affects the argument.


Projects A, C, E, G,... need to be released right now, whereas  
projects B, D, F... are just fine and don't need releases.


IIUC you guys are supposing a parent pom for all these projects in  
"root" and want to be able to run a release on root and have the  
effect be to release just A, C, E, G and the root pom.


No. The root represents the library. The release is of the library,  
not the individual subprojects. I just don't want new versions created  
for subprojects that didn't change.



So if you run a release on root the entire tree will get tagged  
including B, D, F etc that you didn't want tagged.


Actually, I do want them tagged. The "bill of materials" represents a  
release of the whole library. It is just that some of the artifacts in  
the library didn't change. But they should all be part of the release  
tag.



So I think what you want to do is have a quick way to run releases  
on A,C,E,G,... and have each of those tagged individually and not  
tag the whole tree at once.


No. See above.



My impression is that what you are fighting is the scm system, not  
maven.


No. The SCM isn't a problem. However, mvn deploy will try to deploy  
artifacts that haven't changed since the last release. That is bad.  
Nexus should be able to silently ignore those or the deployer should  
somehow be able to detect that the artifact shouldn't be deployed.


Ralph


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

Re: Progress on support for large projects

[Christian Schulte]

Ralph Goers schrieb:
> On May 12, 2009, at 2:43 PM, Brian Fox wrote:
> 
>>>
>>>
>>> As I already said, I talked about release-plugin and my view of the  
>>> world
>>> and it seems NOT to fit together. My POM-tree follows strict logical
>>> aspects that is motivated by the architecture of the project and  
>>> NOT by
>>> the philosophy of some plugin.
>>>
>> I'm trying to understand your structure and motivations behind it,  
>> so if you
>> would care to elaborate, we can be sure to consider these aspects  
>> down the
>> road.
> 
> Well, you've seen mine. Imagine Apache commons where you wanted to run  
> a build from the root of commons. Not everything changes with each  
> release so it is silly to deploy new jar versions that haven't  
> changed.

Why not just remove the modules which haven't changed from the parent ?
The updated parent can still be imported afterwards just as you describe
 and the release plugin could be updated to do this automatically as
well. Instead of failing whenever a non-snapshot version is encountered,
it could just remove that non-snapshot module element from the
corresponding parent and not touch that artifact's version anywhere
during release preparation. That's changing aggregation rules with every
release somehow, I admit.

-- 
Christian


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

Re: Progress on support for large projects

[David Jencks]

On May 12, 2009, at 3:43 PM, Ralph Goers wrote:



On May 12, 2009, at 2:43 PM, Brian Fox wrote:





As I already said, I talked about release-plugin and my view of  
the world

and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of the project and  
NOT by

the philosophy of some plugin.



I'm trying to understand your structure and motivations behind it,  
so if you
would care to elaborate, we can be sure to consider these aspects  
down the

road.


Well, you've seen mine. Imagine Apache commons where you wanted to  
run a build from the root of commons. Not everything changes with  
each release so it is silly to deploy new jar versions that haven't  
changed. So you create a "bill of materials" (bom) pom that has the  
versions of all the subprojects and anything wanting to use a  
commons project can just import that and then specify dependencies  
on the various commons subprojects without specifying a version. But  
to build this all the subprojects need to have the bom pom as their  
parent or grandparent. Thus, any time you change the bom pom version  
every subproject has to change even if nothing changed in it. PITA.


Granted, my "library" isn't as big as commons, put it still  
currently contains 22 pom.xml files that have to be modified each  
time the bom pom changes.


I'm fairly mystified how what you and Jorg appear to want could work  
with any of the scm systems I know about, that tag an entire file  
system subtree at once.  Maybe I don't understand what you guys are  
talking about at all. here's what I think you want:


file system structure showing projects
+root
  +A
  +B
  +C
...
  +D

Probably Jorg has further nesting, but I don't think that actually  
affects the argument.


Projects A, C, E, G,... need to be released right now, whereas  
projects B, D, F... are just fine and don't need releases.


IIUC you guys are supposing a parent pom for all these projects in  
"root" and want to be able to run a release on root and have the  
effect be to release just A, C, E, G and the root pom.


So if you run a release on root the entire tree will get tagged  
including B, D, F etc that you didn't want tagged.


So I think what you want to do is have a quick way to run releases on  
A,C,E,G,... and have each of those tagged individually and not tag the  
whole tree at once.


My impression is that what you are fighting is the scm system, not  
maven.


As far as project setup, what I've done in this situation is have a  
parent pom that isn't "root" but parallel to the projects: all the  
projects use this parent as their parent and obviously dont specify  
its location as "..".  I then construct a pom that builds whatever I'm  
interested in working on in root, but don't check it into svn.  I've  
never had to release more than 2 projects at once in such a setup, so  
just releasing modules individually hasn't been a problem for me.  I  
can see that it would be a problem if I had 10 projects to release at  
once.  I'd think this is additional new functionality for e.g. the  
release plugin rather than something that can be created by modifying  
existing functionality.


I was really confused by this kind of situation until I realized that  
the problems with releasing complicated partial subtrees were caused  
by scm, not maven.  After I arranged the source so tagging would  
correspond to the independent versions I wanted the layout became much  
easier for me to understand.


Does this correspond at all to what you guys are talking about?

thanks
david jencks







Ralph

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




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

Re: Progress on support for large projects

[Ralph Goers]

On May 12, 2009, at 3:01 PM, Joerg Hohwiller wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi again,

I did not yet get the point, why you have to write a new pom.xml to  
the disc.
My naive illusion was that there is a central component that reads  
and parses
the POM in maven where you can hook into and perform the  
transformation.
Then all additional work is to assure, that plugins such as the  
install plugin
do NOT simply copy the pom.xml to the local repo but include the  
transformation.
Here we might run into the problem that the POM XML is de- 
serialized with

a parser (was it XPP or is it StAX) and the internal representation
looses information so it can NOT be serialized again without loosing
indentation, comments, etc. of the original pom.xml.


I read your patch and started to get some parts of the puzzle.

1. The component that reads and parses the POMs is the  
MavenProjectBuilder.

So it is generally possible to do the transformation there.

2. Installing and deploying is NOT diretly done in the according  
plugins,

but in ArtifactInstaller/ArtifactDeployer. Wise decision of the maven
designers so we do NOT have to touch all MOJOs that deal with this.
Still I do NOT know if these plugins need some dependency-update to  
see

such change or if they just depend on the according API and the
implementation (DefaultArtifact*) comes with the artifact-version of  
maven itself.


So maybe my idea is right that for the long run maven developers  
should

think about being able to have a 1:1 (de)serialization possibility
from pom.xml to MavenProject and vice versa. This way one could
make transformations on the POM and ArtifactInstaller/ArtifactDeployer
will serialize the project to XML instead of copying.

But are there some MOJO-hacks out there that also manipulate
the MavenProject and would cause to modify POMs accidently on
install/deploy? Or is it NOT possible for regular MOJO to
change the MavenProject. As far as I see it is just a plain
POJO but it could be proxied or whatever.



I've been "promised" by Jason that the work on Maven 3 is going to fix  
some of these issues. I simply haven't had the time to look at the  
work on Maven 3 and even if I had, it has been changing at a fairly  
rapid pace for months.


While, in principal, Maven's processing is pretty simple - it just  
collects artifacts and runs plugins - the reality is that there are  
lots of side effects and timing issues.


The fix needed to address 2 things; determining the parent pom version  
and resolving variables so that when the pom is deployed to the  
repository the pom isn't ambiguous. That does not include resolving  
variables in dependencies because those are actually OK to not be  
locked down in the repo.  Unfortunately, once the pom is processed it  
is impossible to use the Maven Model object to create a new pom. It  
contains lots of information that wasn't in the original pom that  
shouldn't be in the pom deployed to a repository.  The fix I did took  
care of this effectively. Writing it to an alternate directory and  
then telling maven where it was meant that the artifact deployer  
didn't need any changes at all.


Ralph

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

Re: Progress on support for large projects

[Ralph Goers]

On May 12, 2009, at 2:43 PM, Brian Fox wrote:





As I already said, I talked about release-plugin and my view of the  
world

and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of the project and  
NOT by

the philosophy of some plugin.



I'm trying to understand your structure and motivations behind it,  
so if you
would care to elaborate, we can be sure to consider these aspects  
down the

road.


Well, you've seen mine. Imagine Apache commons where you wanted to run  
a build from the root of commons. Not everything changes with each  
release so it is silly to deploy new jar versions that haven't  
changed. So you create a "bill of materials" (bom) pom that has the  
versions of all the subprojects and anything wanting to use a commons  
project can just import that and then specify dependencies on the  
various commons subprojects without specifying a version. But to build  
this all the subprojects need to have the bom pom as their parent or  
grandparent. Thus, any time you change the bom pom version every  
subproject has to change even if nothing changed in it. PITA.


Granted, my "library" isn't as big as commons, put it still currently  
contains 22 pom.xml files that have to be modified each time the bom  
pom changes.


Ralph

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Brian,

>> As I already said, I talked about release-plugin and my view of the world
>> and it seems NOT to fit together. My POM-tree follows strict logical
>> aspects that is motivated by the architecture of the project and NOT by
>> the philosophy of some plugin.
>>
> 
> I'm trying to understand your structure and motivations behind it, so if you
> would care to elaborate, we can be sure to consider these aspects down the
> road.
> 

Sorry, maybe my words were a little rude (thanks christian btw).
I am also NOT a native speaker...
Thanks for your friendly response though :)

My idea of release-plugin was that if a module in the tree (reactor)
has no snapshot version, it should NOT be released then.
This allows me to open individual snapshots of single modules
without versioning the entire tree (including modules that
have NOT changed at all).

But how would I tell release-plugin to open one module
for development as snapshot and update all other snapshot
modules that depend on it so they point on the proper version.

I started thinking about a swing GUI opened by the plugin
that shows the module tree and allows to change versions
including dependencies on that and shows modules that
point to an older version of a reactor module.

Whenever I thought about it, I came to the point that
the problem is just that you have to change versions
redundant in various POMs. So if you could just omit
the version in case you want to express that you
mean the version from the reactor that is in latest
state on your disc and in your IDE, all problems
were solved.
But as pointed out, when the POM is installed/deployed,
you have to insert the version valid at this time.

It is already possible if you define the versions
all in toplevel pom, set all versions of modules
with packaging "pom" to 1.0 and never change them
semantically in dependency and build sections
and finally add some XSLT MOJO bound to install phase
that transforms the installed pom replacing the version.
A hack so far, but my hope is that it will work
smooth one day with plain native maven standard.

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

iEYEARECAAYFAkoJ9oAACgkQmPuec2Dcv/8c5gCgmYPuA1K7Wg32nvFpFLlemoWr
oAIAnRmVKP801i71yysAVDen9b+BlK0P
=UIdK
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi again,

> I did not yet get the point, why you have to write a new pom.xml to the disc.
> My naive illusion was that there is a central component that reads and parses
> the POM in maven where you can hook into and perform the transformation.
> Then all additional work is to assure, that plugins such as the install plugin
> do NOT simply copy the pom.xml to the local repo but include the 
> transformation.
> Here we might run into the problem that the POM XML is de-serialized with
> a parser (was it XPP or is it StAX) and the internal representation
> looses information so it can NOT be serialized again without loosing
> indentation, comments, etc. of the original pom.xml.

I read your patch and started to get some parts of the puzzle.

1. The component that reads and parses the POMs is the MavenProjectBuilder.
So it is generally possible to do the transformation there.

2. Installing and deploying is NOT diretly done in the according plugins,
but in ArtifactInstaller/ArtifactDeployer. Wise decision of the maven
designers so we do NOT have to touch all MOJOs that deal with this.
Still I do NOT know if these plugins need some dependency-update to see
such change or if they just depend on the according API and the
implementation (DefaultArtifact*) comes with the artifact-version of maven 
itself.

So maybe my idea is right that for the long run maven developers should
think about being able to have a 1:1 (de)serialization possibility
from pom.xml to MavenProject and vice versa. This way one could
make transformations on the POM and ArtifactInstaller/ArtifactDeployer
will serialize the project to XML instead of copying.

But are there some MOJO-hacks out there that also manipulate
the MavenProject and would cause to modify POMs accidently on
install/deploy? Or is it NOT possible for regular MOJO to
change the MavenProject. As far as I see it is just a plain
POJO but it could be proxied or whatever.

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

iEYEARECAAYFAkoJ8dIACgkQmPuec2Dcv/9dcACeL7SEqDxSwuBJMUETpfFEEsRt
3VUAnApJkG7mPAYfF1ADSBslgP1k6lGk
=NAWp
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Christian Edward Gruber]

On May 12, 2009, at 5:43 PM, Brian Fox wrote:
My POM-tree follows strict logical aspects that is motivated by the  
architecture of the project and NOT by the philosophy of some plugin.



You do know these folks are trying to help, right?  ;)

Christian.

Christian Edward Gruber
christianedwardgru...@gmail.com
http://www.geekinasuit.com/


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

Re: Progress on support for large projects

[Brian Fox]

>
>
>
> As I already said, I talked about release-plugin and my view of the world
> and it seems NOT to fit together. My POM-tree follows strict logical
> aspects that is motivated by the architecture of the project and NOT by
> the philosophy of some plugin.
>

I'm trying to understand your structure and motivations behind it, so if you
would care to elaborate, we can be sure to consider these aspects down the
road.

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Fox wrote:
>>
>>> Can you give more details about what doesn't work or doesn't match your
>>> process?
>> E.g. it tried to convince me to release all modules of my entire project
>> and complained if some module had a non SNAPSHOT version.
>>
> 
> Since it's going to convert a module to a release version, you shouldn't
> have to convert them by hand first and thus they would always be snapshots
> in scm. It's true that it will want to release the tree from where ever you
> run it, but that can be mitigated by constructing trees that match how you
> do releases.

As I already said, I talked about release-plugin and my view of the world
and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of the project and NOT by
the philosophy of some plugin.

Thanks anyways for your advice
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoJ7N4ACgkQmPuec2Dcv//5uQCfXQVEGdOCjcCNZp+uMiDUvaFk
MV4AnRewsPtcFh9npnlsvuByNSmxmypN
=tQlc
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Brian Fox]

>
>
> >
> > Can you give more details about what doesn't work or doesn't match your
> > process?
>
> E.g. it tried to convince me to release all modules of my entire project
> and complained if some module had a non SNAPSHOT version.
>

Since it's going to convert a module to a release version, you shouldn't
have to convert them by hand first and thus they would always be snapshots
in scm. It's true that it will want to release the tree from where ever you
run it, but that can be mitigated by constructing trees that match how you
do releases.


>
> >
> 
> >> [cut.]
> >>
> >
> > The new reactor modes are in 2.1.0 that can do some similar things.
> >
> >>
> >> [cut.]
> >
> > Some of this is already done in 2.1.0
>
> Great to hear that. Please give me some hint (weblink, example or whatever)
> to
> get started with this.
>
> Best regards
>   Jörg
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoJ4coACgkQmPuec2Dcv//ZqACgkQiOIFbclxDb1A/cZr1JjyiX
> P4IAn2OiW+XcJizxnzYmmXRzsusBx/7n
> =AinT
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ralph,

>>> Hi there,
>>>
>>> absolutely everybody having large maven projects is
>>> annoyed by maintaining the versions in all the poms.
>>>
>>
>> Are you using the release plugin?
> 
> This problem probably goes away for anyone able to use the release
> plugin, but only because the release plugin does all the work, not
> because the need for the work goes away. If, for whatever reason, you
> can't use the release plugin, then this is a real pain.

Yep, I am having this pain and I now dozens of others that have
the same problems.

>>
>>
>>
>>>
>>> Additionally the complete solution is quite simple
>>> and seems to be quite common sense:
>>>
>>> 1. Allow to omitt versions in  as well
>>> as in  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.
> 
> Actually, the guys I work with started to complain about this again last
> week and want me to fix it. They suggested that rather than tackling
> both accepting a missing parent version and fixing the pom so that the
> pom written to the repository is fully resolved (i.e. the parent version
> is present in the deployed pom) that just accepting the missing parent
> would be enough. I'm not sure, but I'd be willing to look at it.
> 
> I'm also not sure how much things have changed since I created the
> branch. I'll have to check.

I have read your comments.
Well thanks so far for all your work and invest.
I hope you have NOT lost your faith ;)

> 
> The only real problem with what was on the MNG-624 branch was that it
> requires a place to create the resolved pom.xml. To do that it assumed a
> hardcoded location of "target". If a parent pom redefines the build
> directory (it seems really odd to me that this is even allowed) then
> this is wrong. But trying to find the definition of the target variable
> requires looking at every parent, even if it isn't local, which is
> something I was trying to avoid.

I did not yet get the point, why you have to write a new pom.xml to the disc.
My naive illusion was that there is a central component that reads and parses
the POM in maven where you can hook into and perform the transformation.
Then all additional work is to assure, that plugins such as the install plugin
do NOT simply copy the pom.xml to the local repo but include the transformation.
Here we might run into the problem that the POM XML is de-serialized with
a parser (was it XPP or is it StAX) and the internal representation
looses information so it can NOT be serialized again without loosing
indentation, comments, etc. of the original pom.xml.

> 
> Anyone is free to look at the branch and improve on it.
>>
>>
>> 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.
>>
>>
>>>
>>> 2. Ensure that omitted version as well as variables
>>> in   and  are replaced
>>> when a pom is installed in the repository.
>>>
>>
>> Agree with this.
> 
> Yes, the fix in MNG-624 does a really good job of this.

So your patch also resolves variables and NOT only in parent
but also in dependencies-section?
Havent seen that...

>>
>>
>>
>>>
>>> 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 .
>>> 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!
> 
> Where we are in this is that I have been totally booked writing code for
> other projects - mostly commons VFS and commons configuration. 

I have the same problem. The main reason why I am here is because
I am using maven in all my other OSS-projects and I love it but
sometimes I also hate it and hope that the tiny parts that are
not already perfect will go away some day...

> As Brian
> mentioned, he and I discussed this at the last ApacheCon US and found
> the issue noted above. I simply have not had the time to figure out how
> to solve that.  Even if you can't contribute a patch a really good idea
> would be welcomed.

I will try to give it a little dive - but I have NOT done much other
than some MOJO-coding so far and sometimes get lost with mercury,
plexus, wagon, etc. and I have just little time. Still looking for someone
who likes to pay me fo

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Milos,
> 
> relying on the reactor and giving up on being able to build the one project
> separately is very bad (read: completely breaks) any IDE integration.

I totally disagree. I am successfully using maven-eclipse-plugin (mvn
eclipse:eclipse) and this works perfectly with Eclipse except if you
do a lot of filtering. The suggested approach would have no influence on
my IDE, omitted versions would become inter-project-dependencies in eclipse
and everything is fine.

I tried m2eclipse and iam about 20 times and always gave up, because
they were simply NOT able to run my project. E.g. I have source/target
set to 1.5 for compiler-plugin but require 1.6 for development. m2eclipse
thinks that it needs to replace 1.6 with 1.5 wenn I do m2 enable of my project.

However if all the bugs of these plugins would be fixed, and the
"auto-reactor" feature was working, everything could be fine as well
together with the suggested feature. One day there will be eclipse 4.x
and support multi-projects so the entire project (and its reactor)
can be managed as a whole.
I heard this already works for idea.

> 
> Milos
> 

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

iEYEARECAAYFAkoJ47EACgkQmPuec2Dcv//5iACfc1jnc4F33uoOKQ/JFKO8IUuP
x5sAn2m0GO5n32Uz+r0C1Fa23x1PjXxx
=zmBx
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Brian,

>>> 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.
>>
> 
> Can you give more details about what doesn't work or doesn't match your
> process?

E.g. it tried to convince me to release all modules of my entire project
and complained if some module had a non SNAPSHOT version.

> 

>> [cut.]
>>
> 
> The new reactor modes are in 2.1.0 that can do some similar things.
> 
>>
>> [cut.]
> 
> Some of this is already done in 2.1.0

Great to hear that. Please give me some hint (weblink, example or whatever) to
get started with this.

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

iEYEARECAAYFAkoJ4coACgkQmPuec2Dcv//ZqACgkQiOIFbclxDb1A/cZr1JjyiX
P4IAn2OiW+XcJizxnzYmmXRzsusBx/7n
=AinT
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Milos Kleint]

On Sun, May 10, 2009 at 3:09 PM, Joerg Hohwiller wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> >
> >> 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.


relying on the reactor and giving up on being able to build the one project
separately is very bad (read: completely breaks) any IDE integration.

Milos

Re: Progress on support for large projects

[Ralph Goers]

On May 9, 2009, at 7:42 PM, Brian Fox wrote:

On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller hohwiller.de>wrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.



Are you using the release plugin?


This problem probably goes away for anyone able to use the release  
plugin, but only because the release plugin does all the work, not  
because the need for the work goes away. If, for whatever reason, you  
can't use the release plugin, then this is a real pain.






Additionally the complete solution is quite simple
and seems to be quite common sense:

1. Allow to omitt versions in  as well
as in  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.


Actually, the guys I work with started to complain about this again  
last week and want me to fix it. They suggested that rather than  
tackling both accepting a missing parent version and fixing the pom so  
that the pom written to the repository is fully resolved (i.e. the  
parent version is present in the deployed pom) that just accepting the  
missing parent would be enough. I'm not sure, but I'd be willing to  
look at it.


I'm also not sure how much things have changed since I created the  
branch. I'll have to check.


The only real problem with what was on the MNG-624 branch was that it  
requires a place to create the resolved pom.xml. To do that it assumed  
a hardcoded location of "target". If a parent pom redefines the build  
directory (it seems really odd to me that this is even allowed) then  
this is wrong. But trying to find the definition of the target  
variable requires looking at every parent, even if it isn't local,  
which is something I was trying to avoid.


Anyone is free to look at the branch and improve on it.



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.





2. Ensure that omitted version as well as variables
in   and  are replaced
when a pom is installed in the repository.



Agree with this.


Yes, the fix in MNG-624 does a really good job of this.






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 .
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!


Where we are in this is that I have been totally booked writing code  
for other projects - mostly commons VFS and commons configuration. As  
Brian mentioned, he and I discussed this at the last ApacheCon US and  
found the issue noted above. I simply have not had the time to figure  
out how to solve that.  Even if you can't contribute a patch a really  
good idea would be welcomed.


Ralph

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

Re: Progress on support for large projects

[Brian Fox]

> > 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.
>

Can you give more details about what doesn't work or doesn't match your
process?

>
> >>
> >>
> >> Additionally the complete solution is quite simple
> >> and seems to be quite common sense:
> >>
> >> 1. Allow to omitt versions in  as well
> >> as in  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.
>

The new reactor modes are in 2.1.0 that can do some similar things.

>
>
> >>
> >>
> >> 2. Ensure that omitted version as well as variables
> >> in   and  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...
>

Some of this is already done in 2.1.0

>
> >>
> >>
> >> 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 .
> >> 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Progress on support for large projects

[Joerg Hohwiller]

-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  as well
>> as in  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   and  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 .
>> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Progress on support for large projects

[Brian Fox]

On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi there,
>
> absolutely everybody having large maven projects is
> annoyed by maintaining the versions in all the poms.
>

Are you using the release plugin?


>
> Additionally the complete solution is quite simple
> and seems to be quite common sense:
>
> 1. Allow to omitt versions in  as well
> as in  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.

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.


>
> 2. Ensure that omitted version as well as variables
> in   and  are replaced
> when a pom is installed in the repository.
>

Agree with this.


>
> 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 .
> 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
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoF+UIACgkQmPuec2Dcv//gDACfRvtIJ+CrTatgMZiynQ/2/f7+
> 7DQAni6uH3UkGSU0WNFKuUCz5OsyrGy3
> =Jn88
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.

Additionally the complete solution is quite simple
and seems to be quite common sense:

1. Allow to omitt versions in  as well
as in  that is available in the reactor.

2. Ensure that omitted version as well as variables
in   and  are replaced
when a pom is installed in the repository.

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 .
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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoF+UIACgkQmPuec2Dcv//gDACfRvtIJ+CrTatgMZiynQ/2/f7+
7DQAni6uH3UkGSU0WNFKuUCz5OsyrGy3
=Jn88
-END PGP SIGNATURE-

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