You are viewing a plain text version of this content. The canonical link for it is here.
Posted to m2-dev@maven.apache.org by Maczka Michal <mi...@imtf.ch> on 2005/02/21 14:16:11 UTC
Addition to POM & New m2 subproject
Hey!
I started to experiment with a tool which can change pom files and assure
that the same version of some dependency
is used across the board. For that I created new project for making
different type of pom transformations.
I think that this will be also needed for release plugin. In fact I the
first transformation I want to implement is
that one which is happening when project is released (1.1-SNAPSHOT becomes
1.1)
I am just beginning and there is still long way to go but I want to ask if
everybody is agreeing to add new subproject to maven-components.
While playing with it I found some things which are missing in our APIs.
I am operating on maven projects/models using Java API. I need to write back
the changes which I made to XML file.
Those changes should not change much XML file. There are two things
missing to make it possible:
a) Encoding should be kept in maven model so I can pass it to model
marshaler when I will ask it to serialize POM.
b) Number of spaces which is used to indent XML files should be
configurable and not hardcoded to 2 (this is really less important)
As the off topic comment I can add that some things are looking harder then
I expected. For example I am not sure
how to implement "release transformation" while version is inherited from
the parent project or parent project
is in the snapshot state. This basically requires some agreed practices how
pom should be modify during the release process.
Note that latest additions to m2 (e.g shared place where dependecy version
is defined) are not making it simpler.
Other additions to POM which I would like to see:
1) JDK used and required for given project. For example artifact which
claim that they need Java 5 should not be usable by the project
targeting to java 1.3 or 1.4. With transitive dependencies in place
minimal required JDK be detected.
The settings which JDK is used can be also shared by multiple plugins
(e.g. javac, javadoc).
2) I would like to add annotations to particular dependencies which can be
displayed by GUI tools before dependecy version is flipped
(so for example user can decide not to change that version)
I proposing to add something like <comment> tag to Dependency. I think
that those comments are also important for documentation
purpose.
Michal
Re: Addition to POM & New m2 subproject
Posted by Brett Porter <br...@apache.org>.
I agree with Jason and would add to search JIRA first (both MNG and
MAVEN projects) because a lot of POM additions are already in there. I'm
going through the m1 POM changes today to slate them for m2 alphas.
- Brett
Jason van Zyl wrote:
>On Mon, 2005-02-21 at 14:16 +0100, Maczka Michal wrote:
>
>
>>Hey!
>>
>>
>>I started to experiment with a tool which can change pom files and assure
>>that the same version of some dependency
>>is used across the board.
>>
>>
>
>This is what the <dependencyManagement/> section is for in the POM which
>we are experimenting with in the Geronimo, OpenEJB and ActiveMQ builds.
>
>
>
>>For that I created new project for making
>>different type of pom transformations.
>>I think that this will be also needed for release plugin. In fact I the
>>first transformation I want to implement is
>>that one which is happening when project is released (1.1-SNAPSHOT becomes
>>1.1)
>>I am just beginning and there is still long way to go but I want to ask if
>>everybody is agreeing to add new subproject to maven-components.
>>
>>
>
>Have you ever seen the tool that already does this in m1?
>
>I'd like to know more about it before admitting it.
>
>
>
>>While playing with it I found some things which are missing in our APIs.
>>I am operating on maven projects/models using Java API. I need to write back
>>the changes which I made to XML file.
>> Those changes should not change much XML file. There are two things
>>missing to make it possible:
>>
>> a) Encoding should be kept in maven model so I can pass it to model
>>marshaler when I will ask it to serialize POM.
>>
>>
>
>Put that in Modello's JIRA for the generated modello reader/writer.
>That's definitely a good idea.
>
>
>
>> b) Number of spaces which is used to indent XML files should be
>>configurable and not hardcoded to 2 (this is really less important)
>>
>>
>
>Note these in JIRA. There is code in Mevenide which can probably be
>leveraged as they have dealt with these issues extensively for m1.
>
>
>
>>As the off topic comment I can add that some things are looking harder then
>>I expected. For example I am not sure
>>how to implement "release transformation" while version is inherited from
>>the parent project or parent project
>>is in the snapshot state. This basically requires some agreed practices how
>>pom should be modify during the release process.
>>Note that latest additions to m2 (e.g shared place where dependecy version
>>is defined) are not making it simpler.
>>
>>
>
>Sorry, I'm not sure what you're talking about here.
>
>
>
>>Other additions to POM which I would like to see:
>>
>>1) JDK used and required for given project. For example artifact which
>>claim that they need Java 5 should not be usable by the project
>> targeting to java 1.3 or 1.4. With transitive dependencies in place
>>minimal required JDK be detected.
>> The settings which JDK is used can be also shared by multiple plugins
>>(e.g. javac, javadoc).
>>
>>
>
>Put it in JIRA.
>
>
>
>>2) I would like to add annotations to particular dependencies which can be
>>displayed by GUI tools before dependecy version is flipped
>> (so for example user can decide not to change that version)
>> I proposing to add something like <comment> tag to Dependency. I think
>>that those comments are also important for documentation
>> purpose.
>>
>>
>
>Yah, I'm not so sure about this but put them in JIRA and we can discuss
>them. I think we have a pretty good idea of what we are going to shoot
>for in the first release (alpha-1) which is laid out in JIRA.
>
>
>
>>
>>Michal
>>
>>
>>
>>
Re: Addition to POM & New m2 subproject
Posted by Michal Maczka <mm...@interia.pl>.
Jason van Zyl wrote:
>On Mon, 2005-02-21 at 14:16 +0100, Maczka Michal wrote:
>
>
>>Hey!
>>
>>
>>I started to experiment with a tool which can change pom files and assure
>>that the same version of some dependency
>>is used across the board.
>>
>>
>
>This is what the <dependencyManagement/> section is for in the POM which
>we are experimenting with in the Geronimo, OpenEJB and ActiveMQ builds.
>
>
>
Jason!
I know that you are experimenting with the <dependencyManagement/> section.
Honestly I have concerns that this is not going to work and that in end
anyway you will need
a tool which will make a bulk updates of poms (see below)
What I want to implement is completely independent from m2 core. Or to
say more precisely - it uses
m2 artifacts but it requires no changes in maven core.
Why do I think that <dependencyManagement/> thing is not going to work?
Simply because simplicity which it gives in one place it takes it it
another.
Transitive dependencies put strong _requirement_ that wherever you are
releasing
any artifact you have to release every single pom which is need to
"assemble lineage".
And this is very, very different from m1! I took me quite some time to
finally understand this.
It means that SNAPSHOT dependencies should be eliminated from every possible
pom which is involved in that process. This is including poms which are
directly or indirectly
declared as dependencies and from any of parent poms (we have multilevel
inheritance in place!).
Note that there is also important rule which is violated quite commonly
today:
Once things are deployed to the repository - they are frozen (except
SNAPSHOTs artifacts).
and there should be no exception from this rule. The number of poms
which is required to build with m2 is huge comparing to 1 to 3 poms
which we used with m1
(as only project single inheritance existed for long time).
This makes entire thing extremely fragile and requires far more
*scrutiny* and full set of rules which must be followed is yet to discover.
For example it is in my humble opinion very wrong to do things as we are
doing it now for plexus components
(correct me if I am wrong).
We have changed couple of times dependecies in that pom:
http://cvs.plexus.codehaus.org/plexus/plexus-components/pom.xml?rev=1.5&view=auto
and it still have a version 1.0!
This of course is not causing any problems for the people who did those
changes
as he knows that he has to(!!) replace some pom in his local repository.
But for end user who is using one of the plexus components (maybe even
as the one of the transitive dependencies)
and for his version of m2 there is absolutely no way to detect this change.
So we have completely new "physics" which works in m2 land comparing to
what we had for m1
and we have to play accordingly to those new rules and re-think every
things from the scratch, rather
then attempt to solve old m1 problems.
And those new rules are unfortunatly more severe as transitive deps and
the way in which project inheritance works both have some associated
cost with them
That having said I am really __all___ for experimenting with such
features and I will be more that happy if I am mistaken
as this is simply would be great feature!!!
Any way I think that what ever will happen with <dependencyManagement/>
stuff and hoping that it will actually work
I still think that liblary which enbles certain pom transformation will
be anyway needed (e.g by release plugin)
>>For that I created new project for making
>>different type of pom transformations.
>>I think that this will be also needed for release plugin. In fact I the
>>first transformation I want to implement is
>>that one which is happening when project is released (1.1-SNAPSHOT becomes
>>1.1)
>>I am just beginning and there is still long way to go but I want to ask if
>>everybody is agreeing to add new subproject to maven-components.
>>
>>
>
>Have you ever seen the tool that already does this in m1?
>
>I'd like to know more about it before admitting it.
>
>
Unless something changed recently and if I remember this is something
which does XML (DOM) transformations using XPATH expressions.
Release plugin used it for removing snapshot dependecies and chaning the
pom version.
regards
Michal
Re: Addition to POM & New m2 subproject
Posted by Jason van Zyl <ja...@maven.org>.
On Mon, 2005-02-21 at 14:16 +0100, Maczka Michal wrote:
> Hey!
>
>
> I started to experiment with a tool which can change pom files and assure
> that the same version of some dependency
> is used across the board.
This is what the <dependencyManagement/> section is for in the POM which
we are experimenting with in the Geronimo, OpenEJB and ActiveMQ builds.
> For that I created new project for making
> different type of pom transformations.
> I think that this will be also needed for release plugin. In fact I the
> first transformation I want to implement is
> that one which is happening when project is released (1.1-SNAPSHOT becomes
> 1.1)
> I am just beginning and there is still long way to go but I want to ask if
> everybody is agreeing to add new subproject to maven-components.
Have you ever seen the tool that already does this in m1?
I'd like to know more about it before admitting it.
> While playing with it I found some things which are missing in our APIs.
> I am operating on maven projects/models using Java API. I need to write back
> the changes which I made to XML file.
> Those changes should not change much XML file. There are two things
> missing to make it possible:
>
> a) Encoding should be kept in maven model so I can pass it to model
> marshaler when I will ask it to serialize POM.
Put that in Modello's JIRA for the generated modello reader/writer.
That's definitely a good idea.
> b) Number of spaces which is used to indent XML files should be
> configurable and not hardcoded to 2 (this is really less important)
Note these in JIRA. There is code in Mevenide which can probably be
leveraged as they have dealt with these issues extensively for m1.
>
> As the off topic comment I can add that some things are looking harder then
> I expected. For example I am not sure
> how to implement "release transformation" while version is inherited from
> the parent project or parent project
> is in the snapshot state. This basically requires some agreed practices how
> pom should be modify during the release process.
> Note that latest additions to m2 (e.g shared place where dependecy version
> is defined) are not making it simpler.
Sorry, I'm not sure what you're talking about here.
>
>
> Other additions to POM which I would like to see:
>
> 1) JDK used and required for given project. For example artifact which
> claim that they need Java 5 should not be usable by the project
> targeting to java 1.3 or 1.4. With transitive dependencies in place
> minimal required JDK be detected.
> The settings which JDK is used can be also shared by multiple plugins
> (e.g. javac, javadoc).
Put it in JIRA.
> 2) I would like to add annotations to particular dependencies which can be
> displayed by GUI tools before dependecy version is flipped
> (so for example user can decide not to change that version)
> I proposing to add something like <comment> tag to Dependency. I think
> that those comments are also important for documentation
> purpose.
Yah, I'm not so sure about this but put them in JIRA and we can discuss
them. I think we have a pretty good idea of what we are going to shoot
for in the first release (alpha-1) which is laid out in JIRA.
>
>
>
> Michal
>
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau