Re: Maven and Development Process
Niclas Hedhman <[EMAIL PROTECTED]> wrote on 16/04/2004 06:03:04 PM: > On Friday 16 April 2004 05:13, Jason van Zyl wrote: > > > In maven2 > > I find it somewhat disturbing that discussion turns to Maven2 even before > Maven1 is released. > > Is it only me to find this highly awkward?? No, you're not the only one to find this awkward, but open source developers will do what they want, not necessarily work with focus. Brett Porter is pretty much the lead developer on 1.x Jason van Zyl is the lead on 2.x -- dIon Gillard, Multitask Consulting
RE: Maven and Development Process
On Fri, 2004-04-16 at 10:39, Vincent Massol wrote: > > Do you use this sort of setup? > > Yes. I personally don't like XML entity includes. So I'd be happy to > have some built in ways in Maven. I made some proposal a long time ago > on the Maven mailing lists about the ability to define groups of > dependencies, giving them an id and the ability to reference by id. > > The main problem is that we wish all projects to use the same version of > such and such dependency (say version 1.2.8 of log4j for ex). How do you > ensure this? I always used the jar override but in a group setup across projects the group override probably didn't cut it. I just put it in my build.properties but that doesn't work for group dev. This is something that can definitely be fixed in m2. > The solution we have followed was to move all external > dependencies to the top level project.xml so that versions are > controlled in one place. Unfortunately the side effect is that you can't > guess anymore what is the minimal set of dependencies required by such > subproject. Not sure it matters that much but I personally like to know > this kind of information and have some clean stuff. You should definitely be able to do this. > If this use case could be supported it would be great. Here are the > requirements: > 1- ability to define deps in each project > 2- ability to factor some set of dependencies Now with transitive deps you can simply state your dependency on cactus and all its deps will be pull along. Would you still need sets of dependencies with transitive deps working? > 3- ability to say that all deps for such artifact is always for such > version (this third requirement could be satisfied by requirement #2). Yes, for integration work this is essential. So a friendlier JAR override. > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
> -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: 16 April 2004 03:08 > To: Maven Users List > Subject: RE: Maven and Development Process > > On Thu, 2004-04-15 at 17:05, Vincent Massol wrote: > > > Maven2 support recursive inheritance well so would anyone still really > > > need to use entities like this. Ultimately I suppose it doesn't matter > > > how the POM comes together but I would like support to come from Maven > > > itself and not the use of entities which I would consider a > > workaround. > > > > I agree with this. However I'm not sure recursive inheritance is enough. > > If we wish to support all use case, we'll need to support dependencies > > reference as several projects may want to share some references while > > they are not sharing exactly the same set of references. Putting all > > references at the top level would mean that several subprojects which do > > not need all these references will still inherit from them. > > Do you use this sort of setup? Yes. I personally don't like XML entity includes. So I'd be happy to have some built in ways in Maven. I made some proposal a long time ago on the Maven mailing lists about the ability to define groups of dependencies, giving them an id and the ability to reference by id. The main problem is that we wish all projects to use the same version of such and such dependency (say version 1.2.8 of log4j for ex). How do you ensure this? The solution we have followed was to move all external dependencies to the top level project.xml so that versions are controlled in one place. Unfortunately the side effect is that you can't guess anymore what is the minimal set of dependencies required by such subproject. Not sure it matters that much but I personally like to know this kind of information and have some clean stuff. If this use case could be supported it would be great. Here are the requirements: 1- ability to define deps in each project 2- ability to factor some set of dependencies 3- ability to say that all deps for such artifact is always for such version (this third requirement could be satisfied by requirement #2). > > I think that the dep section would be expanded along the tree of POMs > where needed. But one thing I was think about the POM structure was the > possibility of a meta flag to indicate whether an element was overriden > or aggregated. Still not sure if this would be necessary for this type > of scenerio, but there will be some surveys coming along with the maven2 > alpha so we'll find out :-) cool Thanks -Vincent > > > -Vincent > > > > > > > > > > > > > -Original Message- > > > > From: John Casey [mailto:[EMAIL PROTECTED] > > > > Sent: April 15, 2004 1:46 PM > > > > To: Maven Users List > > > > Subject: Re: Maven and Development Process > > > > > > > > Somewhat unfortunately (because it does amount to a lot of work), > > that > > > > is the current best practice, I believe. At any rate, this is > > exactly > > > > what we do. > > > > > > > > -john > > > > > > > > On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > > > > > Hello guys, > > > > > > > > > > I am trying to convert our system from Ant to Maven, I managed to > > > > succesfully migrate all the projects into Maven but right now i am > > > facing > > > > the problem of the development process integration. > > > > > > > > > > I saw there is a Snapshot feature that upload the latest build to > > the > > > > repository, but I am not really sure how does it work? > > > > > > > > > > >From my understanding if i am working on a project composed of > > > several > > > > sub-project, like i do, i need to set in each project.xml file the > > > version > > > > as x.y-dev and then install the articaft produced as > > install-snapshot or > > > > deploy-snapshot for the remote repo > > > > > > > > > > Now in each project that depends on that one, we need to update > > the > > > > version tag of the dependancy to SNAPSHOT and when we build, Maven > > > > automatically download the latest snapshot between the 2 that are in > > the > > > > local and remote repo > > > > > > > > > > When our development is completed we just need to change all the > > > > dependancy version number from snapshot to x.y and the main > >
Re: Maven and Development Process
On Fri, 2004-04-16 at 09:54, Niclas Hedhman wrote: > On Friday 16 April 2004 20:16, Jason van Zyl wrote: > > > > Is it only me to find this highly awkward?? > > > Why would you find it awkward? > > Work is starting on the next generation well before there is a 1.0 release for > the masses to use, sounds like lack of focus on development effort. That's simply not true, when the first alpha release is out there will be more of an explanation, the code for maven2 is not a recent thing. It's been in one form or another for more than a year. Actually, probably longer. > A product like Maven with an extremely high dependency ratio would either need > evolutionary development of the 1.x series or, if the 1.x is so flawed that > the 2.x is necessary, then abandon 1.x before it is released and the support > demand sky-rocket. I'm certain 1 and 2 will co-exist for sometime and the plan is to backport the components in maven2 into maven1 along the 1.x cycle. Even when the first alpha of maven2 is released I doubt anyone is going to jump ship. The 1.0 release is needed and that's what's going to happen. A first beta of maven2 won't be released for months because though entirely functional now it needs to pass through the scrutiny of user feedback. For the time being users should be thankful that by sheer force of will Brett is going to get the 1.0 release out. > So, the awkwardness lies in; We are struggling to get to terms with a > pre-release of 1.0, and get to know that by the time 1.0 hits the shelves, we > would be dying for the 2.0 features, and be back in a pre-release state. The 1.0 release is going to be here for quite a while I imagine. In addition, the biggest, nastiest bugs have been removed in the maven2 components and many of those can be integrated in the 1.x cycle. The plan was to get the 1.0 out without severely radical changes and then integrate the components in along the 1.x path bring the 1.x and 2.x behaviour closer together. > Q; Maybe you can shed some light on what _you_ believe to be release dates for > 1.0 and 2.0 respectively? The 1.0 release is in Brett's hands but looks to be a few weeks away. A few weeks after that I will release the first alpha, but there is a list of criteria that needs to be satisfied first will most likely be longer. But even once that is released there will be series of surveys presented to users on usage patterns, there are use cases we have come up with and during the alphas we will incorporate any additional use cases provided by users. I don't expect the first beta for maven2 to be around until the fall. > > Cheers > Niclas -- jvz. Jason van Zyl [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Development Process
On Friday 16 April 2004 20:16, Jason van Zyl wrote: > > Is it only me to find this highly awkward?? > Why would you find it awkward? Work is starting on the next generation well before there is a 1.0 release for the masses to use, sounds like lack of focus on development effort. A product like Maven with an extremely high dependency ratio would either need evolutionary development of the 1.x series or, if the 1.x is so flawed that the 2.x is necessary, then abandon 1.x before it is released and the support demand sky-rocket. So, the awkwardness lies in; We are struggling to get to terms with a pre-release of 1.0, and get to know that by the time 1.0 hits the shelves, we would be dying for the 2.0 features, and be back in a pre-release state. Q; Maybe you can shed some light on what _you_ believe to be release dates for 1.0 and 2.0 respectively? Cheers Niclas -- +-//---+ | http://www.bali.ac | | http://niclas.hedhman.org | +--//--+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
Return Receipt Your RE: Maven and Development Process document : was Ganesh K Rao/RES/PHRD/SB_PLC received by: at: 04/16/2004 08:21:22 AM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Development Process
On Fri, 2004-04-16 at 04:03, Niclas Hedhman wrote: > On Friday 16 April 2004 05:13, Jason van Zyl wrote: > > > In maven2 > > I find it somewhat disturbing that discussion turns to Maven2 even before > Maven1 is released. It is inevitable that some things will come out but in terms of discussions regarding maven2 but this is nothing in comparison to what will follow. Parallel development occurs frequently, and I have consciously kept the vast majority of material relating to maven2 off list. > Is it only me to find this highly awkward?? Why would you find it awkward? > > Niclas -- jvz. Jason van Zyl [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
I was thinking the exact same thing. -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Friday, April 16, 2004 4:03 AM To: Maven Users List Subject: Re: Maven and Development Process On Friday 16 April 2004 05:13, Jason van Zyl wrote: > In maven2 I find it somewhat disturbing that discussion turns to Maven2 even before Maven1 is released. Is it only me to find this highly awkward?? Niclas -- +-//---+ | http://www.bali.ac | | http://niclas.hedhman.org | +--//--+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
Amato Massimiliano (TLAB) wrote on Friday, April 16, 2004 10:16 AM: >> Jason, >> >> One interesting side-effect of using entities is that if you're >> importing them from an external source (which, if you're not, what's >> the point?) then packaging/deploying a pom to the repo will result >> in an incomplete info set for others d/l'ing that project for a >> recursive build or recursive resolution... > > I am not sure i really got what you meant. I looked over the > entities and i'll implement it in my system but right now I > would like to better understand the side effect you're talking about. No. If you use the maven-dist-plugin to deploy a distribution, the plugin will also distribute the POM. But IMHO it is for a subproject always useless, since you reference with the extend tag also "external" resources as you would do with entities. > As for external source do you also mean internal project > built by another group of developers? If that's the case the > entities would be almost useless since will force each dev to > have all the sources on his computer, instead of importing > the latest snapshot from the remote repo You will need the entity definition. It depends on your setup, if entities are multiproject local or enterprise wirde. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
> Jason, > > One interesting side-effect of using entities is that if you're > importing them from an external source (which, if you're not, what's the > point?) then packaging/deploying a pom to the repo will result in an > incomplete info set for others d/l'ing that project for a recursive > build or recursive resolution... I am not sure i really got what you meant. I looked over the entities and i'll implement it in my system but right now I would like to better understand the side effect you're talking about. As for external source do you also mean internal project built by another group of developers? If that's the case the entities would be almost useless since will force each dev to have all the sources on his computer, instead of importing the latest snapshot from the remote repo Thanks a ton to all for the answers Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Development Process
On Friday 16 April 2004 05:13, Jason van Zyl wrote: > In maven2 I find it somewhat disturbing that discussion turns to Maven2 even before Maven1 is released. Is it only me to find this highly awkward?? Niclas -- +-//---+ | http://www.bali.ac | | http://niclas.hedhman.org | +--//--+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
Okie dokie. I just got the idea and thought I'd run it by ya. I guess it was a little out there. Alex > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 15, 2004 9:38 PM > To: Maven Users List > Subject: RE: Maven and Development Process > > I'm not even sure we need the first form I mentioned, let alone > something like this. I honestly don't like the idea of free form > attributes and a filter. I really don't think something like this is > required. But we'll find out soon enough! L8r, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
John Casey wrote: > Jason, > > One interesting side-effect of using entities is that if you're > importing them from an external source (which, if you're not, what's the > point?) then packaging/deploying a pom to the repo will result in an > incomplete info set for others d/l'ing that project for a recursive > build or recursive resolution... Well, isn't this also true for the extend tag? IIRC jakarta-commons removed them all again because of this. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
Jason van Zyl wrote: > On Thu, 2004-04-15 at 14:38, Mark Langley wrote: >> If you use XML entities to define your version numbers rather than hard >> coding them in the project.xml files, the process of switching between >> snapshot and release versions becomes much easier. >> >> See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities >> for more details. > > Do a lot of people actually use this mechanism? > > Is it simply because maven1 doesn't support recursive inheritance? > > Maven2 support recursive inheritance well so would anyone still really > need to use entities like this. Ultimately I suppose it doesn't matter > how the POM comes together but I would like support to come from Maven > itself and not the use of entities which I would consider a workaround. Yes and no, but entities have their pros and cons. Inheritance is not anything and it depends on the element. E.g. in a multiproject you might have specific developers for the subprojects, but you would like to have them collected in the main project. Also I would not like to inherit always all dependencies from a dependent project, because some dependencies there might only be used to build the package or some are only used for test. E.g. commons-configuration has a dependency for dom4j although I can use the package (well, parts) without. Additionally I would not like to have the test dependencies of it inherited (simple-jndi, hsqldb, commons-db, dbunit, ...). While this component is normally an "external" artifact, I have similar situations in my projects. Using entities you can also create a company-wide repository. The "locator" might point to a webserver. Unfortunately such a "entity repository" makes your POMs quite unmoveable ... Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
On Thu, 2004-04-15 at 21:28, Alex Karasulu wrote: > > > > Do you use this sort of setup? > > > > I think that the dep section would be expanded along the tree of POMs > > where needed. But one thing I was think about the POM structure was the > > possibility of a meta flag to indicate whether an element was overriden > > or aggregated. Still not sure if this would be necessary for this type > > of scenerio, but there will be some surveys coming along with the maven2 > > alpha so we'll find out :-) > > WDYT about flagging dependencies with free form attributes. Then > having an optional inclusion filter in every POM. This filter selects > the dependencies to include in the POM which is having its hierarchy > of dependencies determined dynamically. A filter can work like so: > > (& (isRuntime=tree) (isOptional=true) ) > > If isRuntime and isOptional are dependency attributes then a > 'defined' match can be determined. Otherwise a match is undefined when > these attributes are not present and the net effect is the same as a > failure to match. > > Maven's dependency analyzing code can apply this filter to the > dependencies down the hierarchy until the super set of dependencies > are exhausted. So the effective dependency hierarchy can be controlled > using this filter and such free form attributes to express any > user's specific need. > > WDYT? I'm not even sure we need the first form I mentioned, let alone something like this. I honestly don't like the idea of free form attributes and a filter. I really don't think something like this is required. But we'll find out soon enough! > --Alex > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
> -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 15, 2004 9:08 PM > To: Maven Users List > Subject: RE: Maven and Development Process > > On Thu, 2004-04-15 at 17:05, Vincent Massol wrote: > > > Maven2 support recursive inheritance well so would anyone still really > > > need to use entities like this. Ultimately I suppose it doesn't matter > > > how the POM comes together but I would like support to come from Maven > > > itself and not the use of entities which I would consider a > > workaround. > > > > I agree with this. However I'm not sure recursive inheritance is enough. > > If we wish to support all use case, we'll need to support dependencies > > reference as several projects may want to share some references while > > they are not sharing exactly the same set of references. Putting all > > references at the top level would mean that several subprojects which do > > not need all these references will still inherit from them. > > Do you use this sort of setup? > > I think that the dep section would be expanded along the tree of POMs > where needed. But one thing I was think about the POM structure was the > possibility of a meta flag to indicate whether an element was overriden > or aggregated. Still not sure if this would be necessary for this type > of scenerio, but there will be some surveys coming along with the maven2 > alpha so we'll find out :-) WDYT about flagging dependencies with free form attributes. Then having an optional inclusion filter in every POM. This filter selects the dependencies to include in the POM which is having its hierarchy of dependencies determined dynamically. A filter can work like so: (& (isRuntime=tree) (isOptional=true) ) If isRuntime and isOptional are dependency attributes then a 'defined' match can be determined. Otherwise a match is undefined when these attributes are not present and the net effect is the same as a failure to match. Maven's dependency analyzing code can apply this filter to the dependencies down the hierarchy until the super set of dependencies are exhausted. So the effective dependency hierarchy can be controlled using this filter and such free form attributes to express any user's specific need. WDYT? --Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
On Thu, 2004-04-15 at 17:05, Vincent Massol wrote: > > Maven2 support recursive inheritance well so would anyone still really > > need to use entities like this. Ultimately I suppose it doesn't matter > > how the POM comes together but I would like support to come from Maven > > itself and not the use of entities which I would consider a > workaround. > > I agree with this. However I'm not sure recursive inheritance is enough. > If we wish to support all use case, we'll need to support dependencies > reference as several projects may want to share some references while > they are not sharing exactly the same set of references. Putting all > references at the top level would mean that several subprojects which do > not need all these references will still inherit from them. Do you use this sort of setup? I think that the dep section would be expanded along the tree of POMs where needed. But one thing I was think about the POM structure was the possibility of a meta flag to indicate whether an element was overriden or aggregated. Still not sure if this would be necessary for this type of scenerio, but there will be some surveys coming along with the maven2 alpha so we'll find out :-) > -Vincent > > > > > > > > > -Original Message- > > > From: John Casey [mailto:[EMAIL PROTECTED] > > > Sent: April 15, 2004 1:46 PM > > > To: Maven Users List > > > Subject: Re: Maven and Development Process > > > > > > Somewhat unfortunately (because it does amount to a lot of work), > that > > > is the current best practice, I believe. At any rate, this is > exactly > > > what we do. > > > > > > -john > > > > > > On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > > > > Hello guys, > > > > > > > > I am trying to convert our system from Ant to Maven, I managed to > > > succesfully migrate all the projects into Maven but right now i am > > facing > > > the problem of the development process integration. > > > > > > > > I saw there is a Snapshot feature that upload the latest build to > the > > > repository, but I am not really sure how does it work? > > > > > > > > >From my understanding if i am working on a project composed of > > several > > > sub-project, like i do, i need to set in each project.xml file the > > version > > > as x.y-dev and then install the articaft produced as > install-snapshot or > > > deploy-snapshot for the remote repo > > > > > > > > Now in each project that depends on that one, we need to update > the > > > version tag of the dependancy to SNAPSHOT and when we build, Maven > > > automatically download the latest snapshot between the 2 that are in > the > > > local and remote repo > > > > > > > > When our development is completed we just need to change all the > > > dependancy version number from snapshot to x.y and the main > project.xml > > > version from x.y-dev to x.y as well > > > > > > > > and there restart the cycle > > > > > > > > Is it correct or not? There is a better way to handle the > development > > > process? > > > > > > > > Thanks a ton for your help > > > > Massimiliano > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > 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 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
> -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: 15 April 2004 22:13 > To: Maven Users List > Subject: RE: Maven and Development Process > > On Thu, 2004-04-15 at 14:38, Mark Langley wrote: > > If you use XML entities to define your version numbers rather than hard > > coding them in the project.xml files, the process of switching between > > snapshot and release versions becomes much easier. > > > > See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities > for > > more details. > > Do a lot of people actually use this mechanism? > > Is it simply because maven1 doesn't support recursive inheritance? Yes, mostly. > > Maven2 support recursive inheritance well so would anyone still really > need to use entities like this. Ultimately I suppose it doesn't matter > how the POM comes together but I would like support to come from Maven > itself and not the use of entities which I would consider a workaround. I agree with this. However I'm not sure recursive inheritance is enough. If we wish to support all use case, we'll need to support dependencies reference as several projects may want to share some references while they are not sharing exactly the same set of references. Putting all references at the top level would mean that several subprojects which do not need all these references will still inherit from them. -Vincent > > > > > -Original Message- > > From: John Casey [mailto:[EMAIL PROTECTED] > > Sent: April 15, 2004 1:46 PM > > To: Maven Users List > > Subject: Re: Maven and Development Process > > > > Somewhat unfortunately (because it does amount to a lot of work), that > > is the current best practice, I believe. At any rate, this is exactly > > what we do. > > > > -john > > > > On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > > > Hello guys, > > > > > > I am trying to convert our system from Ant to Maven, I managed to > > succesfully migrate all the projects into Maven but right now i am > facing > > the problem of the development process integration. > > > > > > I saw there is a Snapshot feature that upload the latest build to the > > repository, but I am not really sure how does it work? > > > > > > >From my understanding if i am working on a project composed of > several > > sub-project, like i do, i need to set in each project.xml file the > version > > as x.y-dev and then install the articaft produced as install-snapshot or > > deploy-snapshot for the remote repo > > > > > > Now in each project that depends on that one, we need to update the > > version tag of the dependancy to SNAPSHOT and when we build, Maven > > automatically download the latest snapshot between the 2 that are in the > > local and remote repo > > > > > > When our development is completed we just need to change all the > > dependancy version number from snapshot to x.y and the main project.xml > > version from x.y-dev to x.y as well > > > > > > and there restart the cycle > > > > > > Is it correct or not? There is a better way to handle the development > > process? > > > > > > Thanks a ton for your help > > > Massimiliano > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > 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 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
On Thu, 2004-04-15 at 17:02, Mark Langley wrote: > This allows me to maintain details of each item in exactly one place (the > .ent file), and have them automatically updated in the 5, 10, or 15 projects > that might happen to need them. This is particularly useful for dependencies > - I can guarantee that any module using log4j links to version 1.2.8, then > enforce that they migrate simultaneously to 1.2.9 with a one-line change. I was asking because I believe why this is not possible in maven1 because recursive inheritence isn't support, it is in maven2. > The maintenance time goes way down this way, and as a side benefit our > project.xml files are shorter and much more comprehensible. Certainly, anything that makes the process more comprehensible is a good thing. > I'm not sure why you would consider entities a workaround - they allow you > to define a master list of resources, pick and choose which resources fall > into each project, and keep everything synchronized. In maven2 I believe this can be done without the use of entities, but still it ultimately makes no difference to the XML processing of the POM as long as what maven gets is intact. > One could always > implement the same capability within Maven, but that seems like unnecessary > duplication of effort. The XML parser is giving you this functionality for > free - might as well take advantage of it. It's free in the XML parser, but with the advent of maven2 you'll see things like POMs being stored in DBs and prevayler (which I'm working on) and LDAP (which is something Alex is interested in) and hopefully a variety of other sources. For maven1 it is the only way to make a large set of POMs managable, but for maven2 I don't think it will be necessary but you certainly don't have to change the way you do things. Someone else answered me in IRC and they problem for them was that recursive inheritence doesn't work in maven1 so they needed to entities to make things sane. > Mark > > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: April 15, 2004 4:13 PM > To: Maven Users List > Subject: RE: Maven and Development Process > > On Thu, 2004-04-15 at 14:38, Mark Langley wrote: > > If you use XML entities to define your version numbers rather than hard > > coding them in the project.xml files, the process of switching between > > snapshot and release versions becomes much easier. > > > > See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities > for > > more details. > > Do a lot of people actually use this mechanism? > > Is it simply because maven1 doesn't support recursive inheritance? > > Maven2 support recursive inheritance well so would anyone still really > need to use entities like this. Ultimately I suppose it doesn't matter > how the POM comes together but I would like support to come from Maven > itself and not the use of entities which I would consider a workaround. > > > > > -Original Message- > > From: John Casey [mailto:[EMAIL PROTECTED] > > Sent: April 15, 2004 1:46 PM > > To: Maven Users List > > Subject: Re: Maven and Development Process > > > > Somewhat unfortunately (because it does amount to a lot of work), that > > is the current best practice, I believe. At any rate, this is exactly > > what we do. > > > > -john > > > > On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > > > Hello guys, > > > > > > I am trying to convert our system from Ant to Maven, I managed to > > succesfully migrate all the projects into Maven but right now i am facing > > the problem of the development process integration. > > > > > > I saw there is a Snapshot feature that upload the latest build to the > > repository, but I am not really sure how does it work? > > > > > > >From my understanding if i am working on a project composed of several > > sub-project, like i do, i need to set in each project.xml file the version > > as x.y-dev and then install the articaft produced as install-snapshot or > > deploy-snapshot for the remote repo > > > > > > Now in each project that depends on that one, we need to update the > > version tag of the dependancy to SNAPSHOT and when we build, Maven > > automatically download the latest snapshot between the 2 that are in the > > local and remote repo > > > > > > When our development is completed we just need to change all the > > dependancy version number from snapshot to x.y and the main project.xml > > version from x.y-dev to x.y as well > > > > > > and there restart
RE: Maven and Development Process
Speaking only for myself - I manage a corporate development environment with 14 developers working on about 30 modules in various stages of legacy maintenance, active development, R&D experiments, etc. The set of developers responsible for each module is different, as is the set of dependencies that each project requires. And several modules will often be combined to produce one war artifact, which means that versions of any common dependencies had better match. It's much easier to define employee contact details in developers.ent, a master list of dependencies (internal and external) in dependencies.ent, and then add specific items by reference to each project (e.g.: &dev-johndoe; and &dep-log4j;). This allows me to maintain details of each item in exactly one place (the .ent file), and have them automatically updated in the 5, 10, or 15 projects that might happen to need them. This is particularly useful for dependencies - I can guarantee that any module using log4j links to version 1.2.8, then enforce that they migrate simultaneously to 1.2.9 with a one-line change. The maintenance time goes way down this way, and as a side benefit our project.xml files are shorter and much more comprehensible. I'm not sure why you would consider entities a workaround - they allow you to define a master list of resources, pick and choose which resources fall into each project, and keep everything synchronized. One could always implement the same capability within Maven, but that seems like unnecessary duplication of effort. The XML parser is giving you this functionality for free - might as well take advantage of it. Mark -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 4:13 PM To: Maven Users List Subject: RE: Maven and Development Process On Thu, 2004-04-15 at 14:38, Mark Langley wrote: > If you use XML entities to define your version numbers rather than hard > coding them in the project.xml files, the process of switching between > snapshot and release versions becomes much easier. > > See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for > more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. > > -Original Message- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: April 15, 2004 1:46 PM > To: Maven Users List > Subject: Re: Maven and Development Process > > Somewhat unfortunately (because it does amount to a lot of work), that > is the current best practice, I believe. At any rate, this is exactly > what we do. > > -john > > On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > > Hello guys, > > > > I am trying to convert our system from Ant to Maven, I managed to > succesfully migrate all the projects into Maven but right now i am facing > the problem of the development process integration. > > > > I saw there is a Snapshot feature that upload the latest build to the > repository, but I am not really sure how does it work? > > > > >From my understanding if i am working on a project composed of several > sub-project, like i do, i need to set in each project.xml file the version > as x.y-dev and then install the articaft produced as install-snapshot or > deploy-snapshot for the remote repo > > > > Now in each project that depends on that one, we need to update the > version tag of the dependancy to SNAPSHOT and when we build, Maven > automatically download the latest snapshot between the 2 that are in the > local and remote repo > > > > When our development is completed we just need to change all the > dependancy version number from snapshot to x.y and the main project.xml > version from x.y-dev to x.y as well > > > > and there restart the cycle > > > > Is it correct or not? There is a better way to handle the development > process? > > > > Thanks a ton for your help > > Massimiliano > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] 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 -
RE: Maven and Development Process
Jason, One interesting side-effect of using entities is that if you're importing them from an external source (which, if you're not, what's the point?) then packaging/deploying a pom to the repo will result in an incomplete info set for others d/l'ing that project for a recursive build or recursive resolution... -john On Thu, 2004-04-15 at 16:12, Jason van Zyl wrote: > On Thu, 2004-04-15 at 14:38, Mark Langley wrote: > > If you use XML entities to define your version numbers rather than hard > > coding them in the project.xml files, the process of switching between > > snapshot and release versions becomes much easier. > > > > See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for > > more details. > > Do a lot of people actually use this mechanism? > > Is it simply because maven1 doesn't support recursive inheritance? > > Maven2 support recursive inheritance well so would anyone still really > need to use entities like this. Ultimately I suppose it doesn't matter > how the POM comes together but I would like support to come from Maven > itself and not the use of entities which I would consider a workaround. > > > > > -Original Message- > > From: John Casey [mailto:[EMAIL PROTECTED] > > Sent: April 15, 2004 1:46 PM > > To: Maven Users List > > Subject: Re: Maven and Development Process > > > > Somewhat unfortunately (because it does amount to a lot of work), that > > is the current best practice, I believe. At any rate, this is exactly > > what we do. > > > > -john > > > > On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > > > Hello guys, > > > > > > I am trying to convert our system from Ant to Maven, I managed to > > succesfully migrate all the projects into Maven but right now i am facing > > the problem of the development process integration. > > > > > > I saw there is a Snapshot feature that upload the latest build to the > > repository, but I am not really sure how does it work? > > > > > > >From my understanding if i am working on a project composed of several > > sub-project, like i do, i need to set in each project.xml file the version > > as x.y-dev and then install the articaft produced as install-snapshot or > > deploy-snapshot for the remote repo > > > > > > Now in each project that depends on that one, we need to update the > > version tag of the dependancy to SNAPSHOT and when we build, Maven > > automatically download the latest snapshot between the 2 that are in the > > local and remote repo > > > > > > When our development is completed we just need to change all the > > dependancy version number from snapshot to x.y and the main project.xml > > version from x.y-dev to x.y as well > > > > > > and there restart the cycle > > > > > > Is it correct or not? There is a better way to handle the development > > process? > > > > > > Thanks a ton for your help > > > Massimiliano > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
On Thu, 2004-04-15 at 14:38, Mark Langley wrote: > If you use XML entities to define your version numbers rather than hard > coding them in the project.xml files, the process of switching between > snapshot and release versions becomes much easier. > > See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for > more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. > > -Original Message- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: April 15, 2004 1:46 PM > To: Maven Users List > Subject: Re: Maven and Development Process > > Somewhat unfortunately (because it does amount to a lot of work), that > is the current best practice, I believe. At any rate, this is exactly > what we do. > > -john > > On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > > Hello guys, > > > > I am trying to convert our system from Ant to Maven, I managed to > succesfully migrate all the projects into Maven but right now i am facing > the problem of the development process integration. > > > > I saw there is a Snapshot feature that upload the latest build to the > repository, but I am not really sure how does it work? > > > > >From my understanding if i am working on a project composed of several > sub-project, like i do, i need to set in each project.xml file the version > as x.y-dev and then install the articaft produced as install-snapshot or > deploy-snapshot for the remote repo > > > > Now in each project that depends on that one, we need to update the > version tag of the dependancy to SNAPSHOT and when we build, Maven > automatically download the latest snapshot between the 2 that are in the > local and remote repo > > > > When our development is completed we just need to change all the > dependancy version number from snapshot to x.y and the main project.xml > version from x.y-dev to x.y as well > > > > and there restart the cycle > > > > Is it correct or not? There is a better way to handle the development > process? > > > > Thanks a ton for your help > > Massimiliano > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > Hello guys, > > I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. > > I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? > > >From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo > > Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo > > When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well > > and there restart the cycle > > Is it correct or not? There is a better way to handle the development process? > > Thanks a ton for your help > Massimiliano > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Development Process
Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: > Hello guys, > > I am trying to convert our system from Ant to Maven, I managed to succesfully > migrate all the projects into Maven but right now i am facing the problem of the > development process integration. > > I saw there is a Snapshot feature that upload the latest build to the repository, > but I am not really sure how does it work? > > >From my understanding if i am working on a project composed of several sub-project, > >like i do, i need to set in each project.xml file the version as x.y-dev and then > >install the articaft produced as install-snapshot or deploy-snapshot for the remote > >repo > > Now in each project that depends on that one, we need to update the version tag of > the dependancy to SNAPSHOT and when we build, Maven automatically download the > latest snapshot between the 2 that are in the local and remote repo > > When our development is completed we just need to change all the dependancy version > number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as > well > > and there restart the cycle > > Is it correct or not? There is a better way to handle the development process? > > Thanks a ton for your help > Massimiliano > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven and Development Process
Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? >From my understanding if i am working on a project composed of several sub-project, >like i do, i need to set in each project.xml file the version as x.y-dev and then >install the articaft produced as install-snapshot or deploy-snapshot for the remote >repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
