Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hi guys, I switched to: http://svn.apache.org/repos/asf/tomcat/sandbox/trunk-mvn-build/ and prepare a set of update for OSGi. Unfortunately, it seems that the sandbox is not open to all committer: git svn dcommit Committing to https://svn.apache.org/repos/asf/tomcat/sandbox/trunk-mvn-build ... RA layer request failed: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for '/repos/asf/!svn/ver/1224904/tomcat/sandbox/trunk-mvn-build/tomcat-juli/pom.xml' at /usr/lib/git-core/git-svn line 579 Is it a way to open sandbox (at leat the trunk-mvn-build to all ASF committer ? It will allow me to commit my OSGi changes directly (without submitting a patch to olamy each time). Thanks, Regards JB On 12/23/2011 09:51 AM, Olivier Lamy wrote: Hello, Distro is now ok (at least for unix platform) (common-daemon and tomcat-native now included). Some unit test has been fixed (was broken due to path changes), I'm now at 45 failures on 533 tests (some path changes to fix). Now I have some fixes to do: * version build date in docs included in distro * windauze packaging 2011/12/22 Olivier Lamyol...@apache.org: Hello, I have added the distro packaging (commons-daemon* and tomcat-native.tar.gz not yet done). I still have weird issues which I don't' yet understand: when runing unit test from the top module mvn clean install -Dtest=TestCompositeELResolver GRAVE: Error loading jar:file:/Users/olamy/dev/sources/tomcat/tomcat70/tomcat-catalina/target/tomcat-catalina-7.0.24-SNAPSHOT.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml or using the generated distro mvn clean install -DskipTests I have added for testing convenience an exploded distro so: cd apache-tomcat/target/apache-tomcat-7.0.24-SNAPSHOT-bin/apache-tomcat-7.0.24-SNAPSHOT/bin/ same error in catalina.out 22 d8Ec. 2011 14:21:04 org.apache.tomcat.util.modeler.Registry loadDescriptors GRAVE: Error loading jar:file:/Users/olamy/dev/sources/tomcat/tomcat70/apache-tomcat/target/apache-tomcat-7.0.24-SNAPSHOT-bin/apache-tomcat-7.0.24-SNAPSHOT/lib/catalina.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml I will start debugging. For enable debugging in your ide (after the first install of all dependent modules), you can use: mvn clean install -Dtest=TestCompositeELResolver -pl :tomcat-tests -Dmaven.surefire.debug=true debug port will be 5005. Someone with ideas on the exact cause of this ? 2011/12/21 Olivier Lamyol...@apache.org: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. * sources have been to appropriate modules. * I'm now working on some test which fail (some tests need webapp examples) * distro not yet done. * repackaging of dbcp pool, commons-logging is done using shading technology * I will work with jbonofre (who is karaf committer) to add necessary stuff to osgiing. NOTE: It's really work in progress not finish (so pull requests will be accepted :-) ) 2011/12/20 Mark Thomasma...@apache.org: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turkmt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. I would be very interested in seeing what a Mavenised build of trunk looks like. While I may come across as anti-Maven, that is not my position. I am anti *any* disruptive change that causes more disruption then benefit it brings and right now I see more disruption than I do benefit. I am also wary (from my experience of infrastructure at the ASF) of folks pushing strongly for a switch to something better, promising to help with the switch and promising to support things moving forwards and then melting away just as their support is really needed. A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x, 6.0.x or 5.5.x) at GitHub would help considerably: - we would be able to see how all the potential wrinkles (down-loading JDT, building a packages renamed DBCP, building a package renamed Commons logging, etc) were handled in Maven - we'd be able to judge how much simpler the build process was - Maven newbies like me could try building it, debugging with it and developing with it to see how easy we found it - the work required to create it would demonstrate a commitment to supporting this change I
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hello, Distro is now ok (at least for unix platform) (common-daemon and tomcat-native now included). Some unit test has been fixed (was broken due to path changes), I'm now at 45 failures on 533 tests (some path changes to fix). Now I have some fixes to do: * version build date in docs included in distro * windauze packaging 2011/12/22 Olivier Lamy ol...@apache.org: Hello, I have added the distro packaging (commons-daemon* and tomcat-native.tar.gz not yet done). I still have weird issues which I don't' yet understand: when runing unit test from the top module mvn clean install -Dtest=TestCompositeELResolver GRAVE: Error loading jar:file:/Users/olamy/dev/sources/tomcat/tomcat70/tomcat-catalina/target/tomcat-catalina-7.0.24-SNAPSHOT.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml or using the generated distro mvn clean install -DskipTests I have added for testing convenience an exploded distro so: cd apache-tomcat/target/apache-tomcat-7.0.24-SNAPSHOT-bin/apache-tomcat-7.0.24-SNAPSHOT/bin/ same error in catalina.out 22 d8Ec. 2011 14:21:04 org.apache.tomcat.util.modeler.Registry loadDescriptors GRAVE: Error loading jar:file:/Users/olamy/dev/sources/tomcat/tomcat70/apache-tomcat/target/apache-tomcat-7.0.24-SNAPSHOT-bin/apache-tomcat-7.0.24-SNAPSHOT/lib/catalina.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml I will start debugging. For enable debugging in your ide (after the first install of all dependent modules), you can use: mvn clean install -Dtest=TestCompositeELResolver -pl :tomcat-tests -Dmaven.surefire.debug=true debug port will be 5005. Someone with ideas on the exact cause of this ? 2011/12/21 Olivier Lamy ol...@apache.org: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. * sources have been to appropriate modules. * I'm now working on some test which fail (some tests need webapp examples) * distro not yet done. * repackaging of dbcp pool, commons-logging is done using shading technology * I will work with jbonofre (who is karaf committer) to add necessary stuff to osgiing. NOTE: It's really work in progress not finish (so pull requests will be accepted :-) ) 2011/12/20 Mark Thomas ma...@apache.org: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turk mt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. I would be very interested in seeing what a Mavenised build of trunk looks like. While I may come across as anti-Maven, that is not my position. I am anti *any* disruptive change that causes more disruption then benefit it brings and right now I see more disruption than I do benefit. I am also wary (from my experience of infrastructure at the ASF) of folks pushing strongly for a switch to something better, promising to help with the switch and promising to support things moving forwards and then melting away just as their support is really needed. A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x, 6.0.x or 5.5.x) at GitHub would help considerably: - we would be able to see how all the potential wrinkles (down-loading JDT, building a packages renamed DBCP, building a package renamed Commons logging, etc) were handled in Maven - we'd be able to judge how much simpler the build process was - Maven newbies like me could try building it, debugging with it and developing with it to see how easy we found it - the work required to create it would demonstrate a commitment to supporting this change I should stress that a working Mavenised build of a version of Tomcat is necessary but not sufficient to get my support for a switch from Ant to Maven for the build / release process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 22/12/2011 13:48, Olivier Lamy wrote:
In o.a.t.u.m.Registry with changing
private ModelerSource getModelerSource( String type )
throws Exception
{
if( type==null ) type=MbeansDescriptorsDigesterSource;
//if( type.indexOf( ) 0 ) {
if (type.length()0) {
type=org.apache.tomcat.util.modeler.modules. + type;
}
Class? c = Class.forName(type);
ModelerSource ds=(ModelerSource)c.newInstance();
return ds;
}
package was never added so CNFE.
I wonder what is the need for this test ?
I've look at the code in trunk and it doesn't look quite like the
snippet above.
I'm not sure I understand that question you are asking. Could you
rephrase it?
As an aside, that is (if it isn't clear) a package renamed version of
commons modeler. I believe it is quite old and hasn't been kept in sync
with the changes in modeler. There is also a fair bit of it that isn't
used and could be removed. Running the unused code detector over the
Tomcat 8 source tree is on the todo list. That should remove a lot of
(what I believe is) unnecessary modeler code.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hello,
2011/12/23 Mark Thomas ma...@apache.org:
On 22/12/2011 13:48, Olivier Lamy wrote:
In o.a.t.u.m.Registry with changing
private ModelerSource getModelerSource( String type )
throws Exception
{
if( type==null ) type=MbeansDescriptorsDigesterSource;
//if( type.indexOf( ) 0 ) {
if (type.length()0) {
type=org.apache.tomcat.util.modeler.modules. + type;
}
Class? c = Class.forName(type);
ModelerSource ds=(ModelerSource)c.newInstance();
return ds;
}
package was never added so CNFE.
I wonder what is the need for this test ?
I've look at the code in trunk and it doesn't look quite like the
snippet above.
It's on tc7.0.x branch (
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java
)
BTW as you said for this maven build poc the best is probably to work
against trunk codebase.
What do you think about I commit some stuff in sandbox path ? (
http://svn.apache.org/repos/asf/tomcat/sandbox/trunk-mvn-build )
Maybe it's a path open for all asf committers ? so people interested
to work on that can help ?
Let me know
Thanks
--
Olivier
I'm not sure I understand that question you are asking. Could you
rephrase it?
As an aside, that is (if it isn't clear) a package renamed version of
commons modeler. I believe it is quite old and hasn't been kept in sync
with the changes in modeler. There is also a fair bit of it that isn't
used and could be removed. Running the unused code detector over the
Tomcat 8 source tree is on the todo list. That should remove a lot of
(what I believe is) unnecessary modeler code.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 23/12/2011 12:58, Olivier Lamy wrote:
Hello,
2011/12/23 Mark Thomas ma...@apache.org:
On 22/12/2011 13:48, Olivier Lamy wrote:
In o.a.t.u.m.Registry with changing
private ModelerSource getModelerSource( String type )
throws Exception
{
if( type==null ) type=MbeansDescriptorsDigesterSource;
//if( type.indexOf( ) 0 ) {
if (type.length()0) {
type=org.apache.tomcat.util.modeler.modules. + type;
}
Class? c = Class.forName(type);
ModelerSource ds=(ModelerSource)c.newInstance();
return ds;
}
package was never added so CNFE.
I wonder what is the need for this test ?
I've look at the code in trunk and it doesn't look quite like the
snippet above.
It's on tc7.0.x branch (
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java
)
BTW as you said for this maven build poc the best is probably to work
against trunk codebase.
In this case trunk and 7.0.x/trunk are identical and neither agree with
the code snippet above. I still do not understand what the question is.
What do you think about I commit some stuff in sandbox path ? (
http://svn.apache.org/repos/asf/tomcat/sandbox/trunk-mvn-build )
Maybe it's a path open for all asf committers ? so people interested
to work on that can help ?
Doing the work in the sandbox would certainly make it more visible so
folks on the dev list can see what is happening more easily. We can get
the relevant part of svn published to the ASF Git mirrors if that helps.
Just my $0.02
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/23 Mark Thomas ma...@apache.org:
On 23/12/2011 12:58, Olivier Lamy wrote:
Hello,
2011/12/23 Mark Thomas ma...@apache.org:
On 22/12/2011 13:48, Olivier Lamy wrote:
In o.a.t.u.m.Registry with changing
private ModelerSource getModelerSource( String type )
throws Exception
{
if( type==null ) type=MbeansDescriptorsDigesterSource;
//if( type.indexOf( ) 0 ) {
if (type.length()0) {
type=org.apache.tomcat.util.modeler.modules. + type;
}
Class? c = Class.forName(type);
ModelerSource ds=(ModelerSource)c.newInstance();
return ds;
}
package was never added so CNFE.
I wonder what is the need for this test ?
I've look at the code in trunk and it doesn't look quite like the
snippet above.
It's on tc7.0.x branch (
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java
)
BTW as you said for this maven build poc the best is probably to work
against trunk codebase.
In this case trunk and 7.0.x/trunk are identical and neither agree with
the code snippet above. I still do not understand what the question is.
Ok I miss to explain correctly, the snippet contains change I have
made to get that working.
see
https://github.com/olamy/tomcat70/commit/3cbc6d910c50a1542075b0a2d68de1dac00f2ac0
Without this change package was not added so I add some CNFE.
What do you think about I commit some stuff in sandbox path ? (
http://svn.apache.org/repos/asf/tomcat/sandbox/trunk-mvn-build )
Maybe it's a path open for all asf committers ? so people interested
to work on that can help ?
Doing the work in the sandbox would certainly make it more visible so
folks on the dev list can see what is happening more easily. We can get
the relevant part of svn published to the ASF Git mirrors if that helps.
K I will
Just my $0.02
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 23/12/2011 15:13, Olivier Lamy wrote:
2011/12/23 Mark Thomas ma...@apache.org:
On 23/12/2011 12:58, Olivier Lamy wrote:
Hello,
2011/12/23 Mark Thomas ma...@apache.org:
On 22/12/2011 13:48, Olivier Lamy wrote:
In o.a.t.u.m.Registry with changing
private ModelerSource getModelerSource( String type )
throws Exception
{
if( type==null ) type=MbeansDescriptorsDigesterSource;
//if( type.indexOf( ) 0 ) {
if (type.length()0) {
type=org.apache.tomcat.util.modeler.modules. + type;
}
Class? c = Class.forName(type);
ModelerSource ds=(ModelerSource)c.newInstance();
return ds;
}
package was never added so CNFE.
I wonder what is the need for this test ?
snip/
Ok I miss to explain correctly, the snippet contains change I have
made to get that working.
see
https://github.com/olamy/tomcat70/commit/3cbc6d910c50a1542075b0a2d68de1dac00f2ac0
Without this change package was not added so I add some CNFE.
OK. That change looks wrong to me. The original code is what I would
expect. It is odd that it isn't working if all. The class should be
present. Can you debug it and see what type is on entry to that method?
Maybe the .xml descriptor files aren't where they are expected to be.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 12/21/2011 07:16 PM, Mark Thomas wrote: There hasn't been any activity on this thread for a little while. I don't recall any significant arguments one way or the other for using Nexus or scp+rsync. Since Jean-Frederic has switched all the Maven artifact release scripts to use Nexus, I intend to do the following: - See what happens when I try and do the next Tomcat 7 release using Nexus - Fix anything that doesn't work Don't hesitate to ping me on that. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 22/12/2011 09:17, jean-frederic clere wrote: On 12/21/2011 07:16 PM, Mark Thomas wrote: There hasn't been any activity on this thread for a little while. I don't recall any significant arguments one way or the other for using Nexus or scp+rsync. Since Jean-Frederic has switched all the Maven artifact release scripts to use Nexus, I intend to do the following: - See what happens when I try and do the next Tomcat 7 release using Nexus - Fix anything that doesn't work Don't hesitate to ping me on that. Don't worry, I won't ;) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hello, I have added the distro packaging (commons-daemon* and tomcat-native.tar.gz not yet done). I still have weird issues which I don't' yet understand: when runing unit test from the top module mvn clean install -Dtest=TestCompositeELResolver GRAVE: Error loading jar:file:/Users/olamy/dev/sources/tomcat/tomcat70/tomcat-catalina/target/tomcat-catalina-7.0.24-SNAPSHOT.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml or using the generated distro mvn clean install -DskipTests I have added for testing convenience an exploded distro so: cd apache-tomcat/target/apache-tomcat-7.0.24-SNAPSHOT-bin/apache-tomcat-7.0.24-SNAPSHOT/bin/ same error in catalina.out 22 d8Ec. 2011 14:21:04 org.apache.tomcat.util.modeler.Registry loadDescriptors GRAVE: Error loading jar:file:/Users/olamy/dev/sources/tomcat/tomcat70/apache-tomcat/target/apache-tomcat-7.0.24-SNAPSHOT-bin/apache-tomcat-7.0.24-SNAPSHOT/lib/catalina.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml I will start debugging. For enable debugging in your ide (after the first install of all dependent modules), you can use: mvn clean install -Dtest=TestCompositeELResolver -pl :tomcat-tests -Dmaven.surefire.debug=true debug port will be 5005. Someone with ideas on the exact cause of this ? 2011/12/21 Olivier Lamy ol...@apache.org: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. * sources have been to appropriate modules. * I'm now working on some test which fail (some tests need webapp examples) * distro not yet done. * repackaging of dbcp pool, commons-logging is done using shading technology * I will work with jbonofre (who is karaf committer) to add necessary stuff to osgiing. NOTE: It's really work in progress not finish (so pull requests will be accepted :-) ) 2011/12/20 Mark Thomas ma...@apache.org: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turk mt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. I would be very interested in seeing what a Mavenised build of trunk looks like. While I may come across as anti-Maven, that is not my position. I am anti *any* disruptive change that causes more disruption then benefit it brings and right now I see more disruption than I do benefit. I am also wary (from my experience of infrastructure at the ASF) of folks pushing strongly for a switch to something better, promising to help with the switch and promising to support things moving forwards and then melting away just as their support is really needed. A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x, 6.0.x or 5.5.x) at GitHub would help considerably: - we would be able to see how all the potential wrinkles (down-loading JDT, building a packages renamed DBCP, building a package renamed Commons logging, etc) were handled in Maven - we'd be able to judge how much simpler the build process was - Maven newbies like me could try building it, debugging with it and developing with it to see how easy we found it - the work required to create it would demonstrate a commitment to supporting this change I should stress that a working Mavenised build of a version of Tomcat is necessary but not sufficient to get my support for a switch from Ant to Maven for the build / release process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
In o.a.t.u.m.Registry with changing
private ModelerSource getModelerSource( String type )
throws Exception
{
if( type==null ) type=MbeansDescriptorsDigesterSource;
//if( type.indexOf( ) 0 ) {
if (type.length()0) {
type=org.apache.tomcat.util.modeler.modules. + type;
}
Class? c = Class.forName(type);
ModelerSource ds=(ModelerSource)c.newInstance();
return ds;
}
package was never added so CNFE.
I wonder what is the need for this test ?
2011/12/22 Olivier Lamy ol...@apache.org:
Hello,
I have added the distro packaging (commons-daemon* and
tomcat-native.tar.gz not yet done).
I still have weird issues which I don't' yet understand:
when runing unit test
from the top module
mvn clean install -Dtest=TestCompositeELResolver
GRAVE: Error loading
jar:file:/Users/olamy/dev/sources/tomcat/tomcat70/tomcat-catalina/target/tomcat-catalina-7.0.24-SNAPSHOT.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml
or using the generated distro
mvn clean install -DskipTests
I have added for testing convenience an exploded distro so:
cd
apache-tomcat/target/apache-tomcat-7.0.24-SNAPSHOT-bin/apache-tomcat-7.0.24-SNAPSHOT/bin/
same error in catalina.out
22 d8Ec. 2011 14:21:04 org.apache.tomcat.util.modeler.Registry
loadDescriptors
GRAVE: Error loading
jar:file:/Users/olamy/dev/sources/tomcat/tomcat70/apache-tomcat/target/apache-tomcat-7.0.24-SNAPSHOT-bin/apache-tomcat-7.0.24-SNAPSHOT/lib/catalina.jar!/org/apache/catalina/mbeans/mbeans-descriptors.xml
I will start debugging.
For enable debugging in your ide (after the first install of all
dependent modules), you can use: mvn clean install
-Dtest=TestCompositeELResolver -pl :tomcat-tests
-Dmaven.surefire.debug=true
debug port will be 5005.
Someone with ideas on the exact cause of this ?
2011/12/21 Olivier Lamy ol...@apache.org:
Hello,
I have started some stuff here: https://github.com/olamy/tomcat70.
* sources have been to appropriate modules.
* I'm now working on some test which fail (some tests need webapp examples)
* distro not yet done.
* repackaging of dbcp pool, commons-logging is done using shading technology
* I will work with jbonofre (who is karaf committer) to add necessary
stuff to osgiing.
NOTE: It's really work in progress not finish (so pull requests will
be accepted :-) )
2011/12/20 Mark Thomas ma...@apache.org:
On 20/12/2011 08:17, Antonio Petrelli wrote:
2011/12/19 Mladen Turk mt...@apache.org
On 12/19/2011 07:04 PM, Henri Gomez wrote:
Exactly. Since any change would require a learning curve
and it seems we don't have that many (read none) maven
experts in the house, Gradle could be equally considered,
given that it seems more advanced in customization.
I know well Maven but Olivier (Lamy) is a Maven expert, so there is
friend in the business.
And there is a full Maven PMC not too far ready to provide advices and
help.
Not counting Tomcat consumers ASF projects like OpenEJB.
All I have seen so far is talk and talk and more talk.
There is trunk, branches, sandbox, so anyone is free to
make a proposal and if things work, I'll be the first
one supporting it.
I already forked my own repository from GitHub. I hope to start it after
the holidays.
I would be very interested in seeing what a Mavenised build of trunk
looks like.
While I may come across as anti-Maven, that is not my position. I am
anti *any* disruptive change that causes more disruption then benefit it
brings and right now I see more disruption than I do benefit.
I am also wary (from my experience of infrastructure at the ASF) of
folks pushing strongly for a switch to something better, promising to
help with the switch and promising to support things moving forwards and
then melting away just as their support is really needed.
A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x,
6.0.x or 5.5.x) at GitHub would help considerably:
- we would be able to see how all the potential wrinkles (down-loading
JDT, building a packages renamed DBCP, building a package renamed
Commons logging, etc) were handled in Maven
- we'd be able to judge how much simpler the build process was
- Maven newbies like me could try building it, debugging with it and
developing with it to see how easy we found it
- the work required to create it would demonstrate a commitment to
supporting this change
I should stress that a working Mavenised build of a version of Tomcat is
necessary but not sufficient to get my support for a switch from Ant to
Maven for the build / release process.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
David, On 12/19/11 1:47 PM, David Jencks wrote: As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. Full disclosure: I have no experience with Maven whatsoever. As Tomcat is used by at least some other projects using Maven, it might be courteous to start drinking some of the Kool-Aid there. As someone who has seen the (somewhat) recent and significant improvements to the build process, I can imagine that Maven could continue that trend. Since Olivier is already essentially working on this, and David says his group maintains their own cross-hacked migration process, we might be able to get Tomcat Mavenized with little effort. The only question is how it will affect our core developers, most of who have registered their skepticism about using Maven for the core build process. Would any of the Maven advocates here care to take a good long look at the *entire* set of build scripts and discuss them with one of the core devs? I suspect that the Geronimo team mostly just gets the source, compiles it into JARs and includes it in that product distribution. Do you guys run all the unit tests, or do you rely on the Tomcat team to have that taken care of already? Are there other procedures that may have been ... overlooked in your side-loading-into Maven? Obviously, it's important that development on Tomcat doesn't grind to a halt because the new build process isn't complete. -chris signature.asc Description: OpenPGP digital signature
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Two cents from a side On Tue, Dec 20, 2011 at 11:21 PM, Sylvain Laurent sylvain.laur...@m4x.org wrote: On 20 déc. 2011, at 12:22, Mark Thomas wrote: Where I disagree is on whether a switch to Maven lowers that barrier to entry. I agree it lowers it for folks that already know Maven but don't know Ant but that it raises it for folks that know Ant but don't know Maven. Knowing ant does not mean knowing how to build a particular project. That's the big drawback of ant over maven : there's no convention/standard way of doing things. IMHO knowing maven is worth the investment and can be applied to so many projects that the return on investment is quite quick. whether I run ant release or mvn clean install there is no real difference to a new user, so I'd deny the argument. And in any complex build there are at least as many possibilities to achieve something with mvn as with ant, so standardization of the poms is a myth which mvn tries to sell (To start with something parent and aggregator in one pom or different, aggregator in parent folder or separate folder etc). Having said this, we moved all our projects to mvn about a year ago and we did't regret it. We did mainly because of dependency/publication management (after trying to publish to nexus with ant-ivy for three month) and reproducibility of builds. Together with jenkins/hudson integration it was a total win. /2 cents regards Leon - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
There hasn't been any activity on this thread for a little while. I don't recall any significant arguments one way or the other for using Nexus or scp+rsync. Since Jean-Frederic has switched all the Maven artifact release scripts to use Nexus, I intend to do the following: - See what happens when I try and do the next Tomcat 7 release using Nexus - Fix anything that doesn't work - Review the ease of use of scp+rsync and Nexus and if there are issues, complexities etc with Nexus switch back to scp+rsync otherwise stick with Nexus Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hello, I have started some stuff here: https://github.com/olamy/tomcat70. * sources have been to appropriate modules. * I'm now working on some test which fail (some tests need webapp examples) * distro not yet done. * repackaging of dbcp pool, commons-logging is done using shading technology * I will work with jbonofre (who is karaf committer) to add necessary stuff to osgiing. NOTE: It's really work in progress not finish (so pull requests will be accepted :-) ) 2011/12/20 Mark Thomas ma...@apache.org: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turk mt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. I would be very interested in seeing what a Mavenised build of trunk looks like. While I may come across as anti-Maven, that is not my position. I am anti *any* disruptive change that causes more disruption then benefit it brings and right now I see more disruption than I do benefit. I am also wary (from my experience of infrastructure at the ASF) of folks pushing strongly for a switch to something better, promising to help with the switch and promising to support things moving forwards and then melting away just as their support is really needed. A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x, 6.0.x or 5.5.x) at GitHub would help considerably: - we would be able to see how all the potential wrinkles (down-loading JDT, building a packages renamed DBCP, building a package renamed Commons logging, etc) were handled in Maven - we'd be able to judge how much simpler the build process was - Maven newbies like me could try building it, debugging with it and developing with it to see how easy we found it - the work required to create it would demonstrate a commitment to supporting this change I should stress that a working Mavenised build of a version of Tomcat is necessary but not sufficient to get my support for a switch from Ant to Maven for the build / release process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hi all, I just discussed with Olivier about that. I will help OSGiing Tomcat. I would like to enhance Pax Web to be able to support both Jetty (as currently) and Tomcat using OSGi service selector. I plan to push the OSGi changes tomorrow on the Olivier's github. Regards JB On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. * sources have been to appropriate modules. * I'm now working on some test which fail (some tests need webapp examples) * distro not yet done. * repackaging of dbcp pool, commons-logging is done using shading technology * I will work with jbonofre (who is karaf committer) to add necessary stuff to osgiing. NOTE: It's really work in progress not finish (so pull requests will be accepted :-) ) 2011/12/20 Mark Thomasma...@apache.org: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turkmt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. I would be very interested in seeing what a Mavenised build of trunk looks like. While I may come across as anti-Maven, that is not my position. I am anti *any* disruptive change that causes more disruption then benefit it brings and right now I see more disruption than I do benefit. I am also wary (from my experience of infrastructure at the ASF) of folks pushing strongly for a switch to something better, promising to help with the switch and promising to support things moving forwards and then melting away just as their support is really needed. A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x, 6.0.x or 5.5.x) at GitHub would help considerably: - we would be able to see how all the potential wrinkles (down-loading JDT, building a packages renamed DBCP, building a package renamed Commons logging, etc) were handled in Maven - we'd be able to judge how much simpler the build process was - Maven newbies like me could try building it, debugging with it and developing with it to see how easy we found it - the work required to create it would demonstrate a commitment to supporting this change I should stress that a working Mavenised build of a version of Tomcat is necessary but not sufficient to get my support for a switch from Ant to Maven for the build / release process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. Otherwise no one will be able to apply custom patches to the exiting code base. BTW, Oliver, it looks really nice! Have couple of suggestion, but we need to solve #1 first. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 21/12/2011 21:21, Mladen Turk wrote: On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. I'm not sure we need a new branch if the end result is going to be the same. How we merge patches from trunk - 7.0.x - 6.0.x is something that is going to need to be addressed. I would have started with trunk rather than 7.0.x but they are close enough that what works for one should work for the other. Otherwise no one will be able to apply custom patches to the exiting code base. Yep, that is a problem we need to solve. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 10:24 PM, Mark Thomas wrote: On 21/12/2011 21:21, Mladen Turk wrote: On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. I'm not sure we need a new branch if the end result is going to be the same. Well, we would screw anyone doing derivative work, that's for sure. Also any distribution packaging tomcat will have serious problems as well since almost all of them use package dependencies instead download or maven tasks. Eg, take a look at https://github.com/vanaf/tomcat7-fedora/blob/master/tomcat.spec OpenSuse is almost the same (they add some Geronimo dependencies however) In essence no packages will be able to change the version unless he rewrites the .spec or debian files from scratch thought. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 21/12/2011 21:57, Mladen Turk wrote: On 12/21/2011 10:24 PM, Mark Thomas wrote: On 21/12/2011 21:21, Mladen Turk wrote: On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. I'm not sure we need a new branch if the end result is going to be the same. Well, we would screw anyone doing derivative work, that's for sure. Also any distribution packaging tomcat will have serious problems as well since almost all of them use package dependencies instead download or maven tasks. Eg, take a look at https://github.com/vanaf/tomcat7-fedora/blob/master/tomcat.spec OpenSuse is almost the same (they add some Geronimo dependencies however) In essence no packages will be able to change the version unless he rewrites the .spec or debian files from scratch thought. Ouch. That is argument for only doing this in trunk, if we do it at all. Still need to figure out how to merge patches if we go that way. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 11:01 PM, Mark Thomas wrote: On 21/12/2011 21:57, Mladen Turk wrote: In essence no packages will be able to change the version unless he rewrites the .spec or debian files from scratch thought. Ouch. That is argument for only doing this in trunk, if we do it at all. Right. Up till now all linux distributions were using tomcatX, so yes, Tomcat8 (trunk) is the logical target. Still need to figure out how to merge patches if we go that way. If they do not span across new 'modules' it should be just making sure they are executed using 'patch -pX' so that correct number of directory entries is stripped from patch header. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
+1 - Romain 2011/12/20 David Jencks david_jen...@yahoo.com On Dec 19, 2011, at 1:06 PM, jean-frederic clere wrote: On 12/19/2011 07:47 PM, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. So starting with what is in the geronimo repo, how much work would it to have a mavenized Tomcat? I did this work and suggested tomcat look at it several years ago, and don't remember all the details, some other people have been maintaining it recently. IIRC the maven projects generate pretty much the same jars as the ant build, possibly plus one more to get around the circular dependencies among the jars. So to generate a maven multimodule project to build the jars, 20 min to configure the script that builds the project, then you have a mavenized tomcat project checked in that builds pretty much the same jars as the ant build. I don't really know what else the ant build generates. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. We already publish artifacs, do you need more of them? I think the benefit might be more on the order of encouraging people who ask where did this jar come from-- I wanna fix something. For people familiar with maven, there is IMO a much higher barrier to contributing to tomcat than a well-structured maven project. (BTW I must add that I'm delighted that the tomcat community seems much more receptive to outside input than it did several years ago -- community unfriendliness seems to be totally missing now :-) ). thanks david jencks Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/19 Mladen Turk mt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/19 David Jencks david_jen...@yahoo.com Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. David, I think that I will use that stuff, do you mind if I do? :-D Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/20/2011 08:58 AM, David Jencks wrote: did this work and suggested tomcat look at it several years ago, and don't remember all the details, some other people have been maintaining it recently. IIRC the maven projects generate pretty much the same jars as the ant build, possibly plus one more to get around the circular dependencies among the jars. I think it is fixed in trunk. So to generate a maven multimodule project to build the jars, 20 min to configure the script that builds the project, then you have a mavenized tomcat project checked in that builds pretty much the same jars as the ant build. I don't really know what else the ant build generates. Hm that means that we should be able to switch to maven in a day or 2, I will try that next week then ;-) Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/20/2011 09:17 AM, Antonio Petrelli wrote: 2011/12/19 Mladen Turkmt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. Please publish the url... I can fork it and play there too. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/20 jean-frederic clere jfcl...@gmail.com On 12/20/2011 09:17 AM, Antonio Petrelli wrote: 2011/12/19 Mladen Turkmt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. Please publish the url... I can fork it and play there too. Whoops! I had to do it before :-) First of all, Git is read-only at Apache: http://git.apache.org/ In this page there are many Gitted projects for Tomcat. My current fork is for Tomcat 7: https://github.com/apetrelli/tomcat70 However, since the fork, I did not pushed anything yet. Antonio Cheers Jean-Frederic --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/19 Pid p...@pidster.com On 18/12/2011 08:37, Mladen Turk wrote: On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I was wondering if someone would mention Gradle. If there's a build tool shootout to be had, Gradle should get fair consideration. I tried Gradle some time ago and, IMHO, it is pretty slow compared to Maven 3. Moreover, m2eclipse and Maven have some developers in common and are doing a great work to integrate the various plugins. The Eclipse-Gradle plugin seems not much mature IMHO. However, point in the right direction if I missed something :-) Thanks Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/20 Antonio Petrelli antonio.petre...@gmail.com: 2011/12/20 jean-frederic clere jfcl...@gmail.com On 12/20/2011 09:17 AM, Antonio Petrelli wrote: 2011/12/19 Mladen Turkmt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. Please publish the url... I can fork it and play there too. Whoops! I had to do it before :-) First of all, Git is read-only at Apache: http://git.apache.org/ In this page there are many Gitted projects for Tomcat. My current fork is for Tomcat 7: https://github.com/apetrelli/tomcat70 However, since the fork, I did not pushed anything yet. Have a look at the maven layout I have done here: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/maven/ It produces the same artifacts (except distrib) all tests are in a module. It's just a question of moving sources. Let me know if you want I push/commit some other changes in a branch somewhere with sources move and start to work on assembly stuff. Antonio Cheers Jean-Frederic --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/20 Antonio Petrelli antonio.petre...@gmail.com: 2011/12/19 Pid p...@pidster.com On 18/12/2011 08:37, Mladen Turk wrote: On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I was wondering if someone would mention Gradle. If there's a build tool shootout to be had, Gradle should get fair consideration. I tried Gradle some time ago and, IMHO, it is pretty slow compared to Maven 3. Moreover, m2eclipse and Maven have some developers in common and are doing a great work to integrate the various plugins. The Eclipse-Gradle plugin seems not much mature IMHO. The current version of m2e(clipse) in its default configuration (re)downloads 200Mb index file from Maven Central into my workspace, hanging IDE in the process. What is worse that it does that regardless of whether any projects in this workspace use Maven. I would not say that the issue is fatal, and it should not take a year to fix it, but judging just the current version I'd say it is not mature enough. Ant is surely easier to run and it comes with IDE by default. If one wants to convince me in using Maven - I would very like to see a release of Tomcat taglibs subproject. It looks we are stalled there. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/20 Konstantin Kolinko knst.koli...@gmail.com The current version of m2e(clipse) in its default configuration (re)downloads 200Mb index file from Maven Central into my workspace, hanging IDE in the process. Never seen that... Or, at least, it does not hang. Ant is surely easier to run and it comes with IDE by default. But it does not come with library mapping, not because of Ant problems, but because Ant build scripts are always customized. There is no way to create a consistent plugin inside Eclipse for Ant, the only thing that an IDE can do is running Ant targets. If one wants to convince me in using Maven - I would very like to see a release of Tomcat taglibs subproject. It looks we are stalled there. I think that you should start another thread for this. Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 20/12/2011 03:21, David Jencks wrote: Thanks for your brevity, Mark On Dec 19, 2011, at 11:24 AM, Mark Thomas wrote: I'll try and keep this response short too, but these are non-trivial issues... On 19/12/2011 18:47, David Jencks wrote: I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build more time on this. I'm curious. What are the benefits of doing this over using the JARs that Tomcat already publishes to Maven central? Is there something wrong / missing with those JARs? If so, it can probably be fixed. Geronimo originally needed a way we could track to apply patches. I don't know that we have needed any patches recently, but we now need osgi bundles. If Geronimo prefers a 100% Maven build and needs to patch Tomcat then I can see why you created the Mavenised layout. However, I don't see that as a good reason for changing Tomcat's build layout. There are other folks that consume Tomcat that prefer the 100% Ant approach. If there was an overwhelming majority for Maven then the switch could make sense just for that reason but I don't see an overwhelming majority one way or the other at the moment. Therefore, on this point, the status quo is the right answer in my view. OSGI bundles are a new requirement. And one that I don't recall seeing mentioned on the dev or users list. Is this just a Geronimo requirement or is there likely to be a wider demand for these? If it is just Geronimo then it might be easier to just leave this in Geronimo. If there is a wider demand, then the Tomcat project should probably take ownership of this. I have lots of questions on this which probably don't belong on this thread. If you think it would be better for the Tomcat project to produce these then please create an enhancement request and the details can be worked out there. If there is an easy way to create these in Maven and creating them with the Ant script is difficult / painful / error prone, then that would be an argument in favour of Maven. How strong that argument is would depend on how easy it was to do this with Maven and how big the problems were with doing this with Ant. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. How does building with Maven encourage interaction with other communities over and above the interaction we see via publishing the JARS to Maven central that we already publish? I generally wont work on projects that aren't maven based because the project layout and build system usually takes too long for me to understand to be worth it for the possible contribution I might make. I feel exactly the opposite and tend to avoid projects that use Maven for exactly the same reasons. Now that Geronimo has a mavenized tomcat, I can consider working on tomcat problems in the mavenized copy and if I think it's worth the trouble try to generate a patch against the original tomcat source. I think the standardization maven brings makes projects much more friendly to outsiders looking to contribute. And I think Maven adds complexity and magic that makes it harder for folks to figure out what is going on. As I have said elsewhere, a lot of this comes down to how familiar you are with the tool. I'm not against learning how to use Maven, if the return is worth the investment. I remain to be convinced that that is the case. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/20 Mark Thomas ma...@apache.org If there is an easy way to create these in Maven and creating them with the Ant script is difficult / painful / error prone, then that would be an argument in favour of Maven. How strong that argument is would depend on how easy it was to do this with Maven and how big the problems were with doing this with Ant. The Maven Felix plugin uses dependencies to create OSGi Bundles with little, or no, configuration (there are some corner cases). Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 20/12/2011 07:58, David Jencks wrote: I think the benefit might be more on the order of encouraging people who ask where did this jar come from-- I wanna fix something. For people familiar with maven, there is IMO a much higher barrier to contributing to tomcat than a well-structured maven project. I'm not sure I agree with this one. I think when folks find a bug they don't know which JAR the bug is in. A little debugging will (hopefully) tell them which class rather than which JAR the bug is in. Finding that class in a single source tree is arguably easier than trying to find it in multiple source trees. I do agree that compiling a fixed version of the JAR will be easier using Maven, if the user understands Maven but then we are back to folks that know Maven find Maven easier whereas folks that don't know Maven, find Maven harder. I agree that we need to have as low a barrier to entry as possible. The work that has been done on the build scripts has improved things significantly since I started work on Tomcat. I can hardly believe how much of a pain building a Tomcat 4.1.x release was compared to how easy 7.0.x is. Where I disagree is on whether a switch to Maven lowers that barrier to entry. I agree it lowers it for folks that already know Maven but don't know Ant but that it raises it for folks that know Ant but don't know Maven. (BTW I must add that I'm delighted that the tomcat community seems much more receptive to outside input than it did several years ago -- community unfriendliness seems to be totally missing now :-) ). That is good. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turk mt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. I would be very interested in seeing what a Mavenised build of trunk looks like. While I may come across as anti-Maven, that is not my position. I am anti *any* disruptive change that causes more disruption then benefit it brings and right now I see more disruption than I do benefit. I am also wary (from my experience of infrastructure at the ASF) of folks pushing strongly for a switch to something better, promising to help with the switch and promising to support things moving forwards and then melting away just as their support is really needed. A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x, 6.0.x or 5.5.x) at GitHub would help considerably: - we would be able to see how all the potential wrinkles (down-loading JDT, building a packages renamed DBCP, building a package renamed Commons logging, etc) were handled in Maven - we'd be able to judge how much simpler the build process was - Maven newbies like me could try building it, debugging with it and developing with it to see how easy we found it - the work required to create it would demonstrate a commitment to supporting this change I should stress that a working Mavenised build of a version of Tomcat is necessary but not sufficient to get my support for a switch from Ant to Maven for the build / release process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 20/12/2011 09:05, Olivier Lamy wrote: 2011/12/20 Antonio Petrelli antonio.petre...@gmail.com: Whoops! I had to do it before :-) First of all, Git is read-only at Apache: http://git.apache.org/ In this page there are many Gitted projects for Tomcat. My current fork is for Tomcat 7: https://github.com/apetrelli/tomcat70 However, since the fork, I did not pushed anything yet. Have a look at the maven layout I have done here: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/maven/ It produces the same artifacts (except distrib) all tests are in a module. It's just a question of moving sources. Let me know if you want I push/commit some other changes in a branch somewhere with sources move and start to work on assembly stuff. I'd suggest that the GitHub fork is the place to collaborate as we have both committers and non-committers wanting to work on this. I would add that a Maven build that produces everything the current Ant build does is necessary but not sufficient to get my support for a move from Ant to Maven. (feel free to replace Maven with Gradle or a.n.other build system in the paragraph above). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/20 Mark Thomas ma...@apache.org On 20/12/2011 09:05, Olivier Lamy wrote: 2011/12/20 Antonio Petrelli antonio.petre...@gmail.com: Whoops! I had to do it before :-) First of all, Git is read-only at Apache: http://git.apache.org/ In this page there are many Gitted projects for Tomcat. My current fork is for Tomcat 7: https://github.com/apetrelli/tomcat70 However, since the fork, I did not pushed anything yet. Have a look at the maven layout I have done here: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/maven/ It produces the same artifacts (except distrib) all tests are in a module. It's just a question of moving sources. Let me know if you want I push/commit some other changes in a branch somewhere with sources move and start to work on assembly stuff. I'd suggest that the GitHub fork is the place to collaborate as we have both committers and non-committers wanting to work on this. Thanks, I'm ok with this. However if a Maven committer forks at GitHub and, then, other Maven non-committers fork from it would be easier, because this way the committer might merge the pull requests and commit (if he likes it). Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/20 Antonio Petrelli antonio.petre...@gmail.com 2011/12/20 Mark Thomas ma...@apache.org On 20/12/2011 09:05, Olivier Lamy wrote: 2011/12/20 Antonio Petrelli antonio.petre...@gmail.com: Whoops! I had to do it before :-) First of all, Git is read-only at Apache: http://git.apache.org/ In this page there are many Gitted projects for Tomcat. My current fork is for Tomcat 7: https://github.com/apetrelli/tomcat70 However, since the fork, I did not pushed anything yet. Have a look at the maven layout I have done here: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/maven/ It produces the same artifacts (except distrib) all tests are in a module. It's just a question of moving sources. Let me know if you want I push/commit some other changes in a branch somewhere with sources move and start to work on assembly stuff. I'd suggest that the GitHub fork is the place to collaborate as we have both committers and non-committers wanting to work on this. Thanks, I'm ok with this. However if a Maven committer forks at GitHub and, then, other Maven non-committers fork from it would be easier, because this way the committer might merge the pull requests and commit (if he likes it). Probably I said a stupid thing, ignore it... It's time to eat and I need calories :-D Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 20/12/2011 08:38, Antonio Petrelli wrote: 2011/12/19 Pid p...@pidster.com On 18/12/2011 08:37, Mladen Turk wrote: On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I was wondering if someone would mention Gradle. If there's a build tool shootout to be had, Gradle should get fair consideration. I tried Gradle some time ago and, IMHO, it is pretty slow compared to Maven 3. Gradle are releasing frequently, it would be worth trying again. Moreover, m2eclipse and Maven have some developers in common and are doing a great work to integrate the various plugins. The Eclipse-Gradle plugin seems not much mature IMHO. Have you tried that recently? It has been working OK for me - but then I prefer to do the build stuff from the CLI anyway. However, point in the right direction if I missed something :-) Plenty of new things to read in the changelog. A notable feature of Gradle is that it does not require the build tool to be pre-installed, it provides a wrapper mechanism that downloads the specified version of the tool when it runs. I think that the syntax of the Gradle DSL is easier to understand than Maven (certainly for new users) and it happily integrates with various of the popular repos and other build tool plugins. Seems like the best of both worlds to me. p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Another good thing in gradle is its incremental build support. - Romain 2011/12/20 Pid p...@pidster.com On 20/12/2011 08:38, Antonio Petrelli wrote: 2011/12/19 Pid p...@pidster.com On 18/12/2011 08:37, Mladen Turk wrote: On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I was wondering if someone would mention Gradle. If there's a build tool shootout to be had, Gradle should get fair consideration. I tried Gradle some time ago and, IMHO, it is pretty slow compared to Maven 3. Gradle are releasing frequently, it would be worth trying again. Moreover, m2eclipse and Maven have some developers in common and are doing a great work to integrate the various plugins. The Eclipse-Gradle plugin seems not much mature IMHO. Have you tried that recently? It has been working OK for me - but then I prefer to do the build stuff from the CLI anyway. However, point in the right direction if I missed something :-) Plenty of new things to read in the changelog. A notable feature of Gradle is that it does not require the build tool to be pre-installed, it provides a wrapper mechanism that downloads the specified version of the tool when it runs. I think that the syntax of the Gradle DSL is easier to understand than Maven (certainly for new users) and it happily integrates with various of the popular repos and other build tool plugins. Seems like the best of both worlds to me. p -- [key:62590808]
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 20 déc. 2011, at 12:22, Mark Thomas wrote: Where I disagree is on whether a switch to Maven lowers that barrier to entry. I agree it lowers it for folks that already know Maven but don't know Ant but that it raises it for folks that know Ant but don't know Maven. Knowing ant does not mean knowing how to build a particular project. That's the big drawback of ant over maven : there's no convention/standard way of doing things. IMHO knowing maven is worth the investment and can be applied to so many projects that the return on investment is quite quick. Regarding maven for tomcat, I think it would lower the barrier of entry for new developers. In a perfect maven scenario, a developer would checkout tomcat sources in its IDE, wait for the dependencies to be downloaded and have a workspace ready to hack into tomcat using standard maven commands. so, I'm +1 to support any experiments around maven and then judge on the results. Sylvain - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/18 Mladen Turk mt...@apache.org On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. In fact I feel as a Maven evangelist. There is a thing that I like of Maven most: Check out as Maven project of m2eclipse. In one shot I have all the projects under my workspace, without any library problem, every single time. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. Moving from Ant to Maven is not an easy path, since there is the need of a great reorganization. I already did it for a few work projects, and one project at Apache. If someone does not know the phylosophy of Maven, it's better not to try Mavenizing it, because usually the project structure under a specific build script with Ant is so spaghettified that it needs to be sorted out. I won't support such a transition at this moment. No problem for you, it's my problem. I see it as an exercise. Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. So standardization is no benefit? Do you mean that an external developer, that sees a common project structure that can start working on it easily, is not a benefit? 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. Do you think that having a single source tree and letting Ant script reconstruct in some non-obvious way the jars, is a benefit? The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Checkstyle checks unwanted *imports* not dependencies. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. Real modularity means: one source directory - one jar. In other cases, it is not obvious. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? The benefit is that the pom.xml is similar to other projects. After you see a kind of project, you see almost them all. 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? See above. 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? You don't need to maintain a build script, but only use a plugin. Most of the time, it's just the matter of including it. 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). Does ant release tag automatically and prepare for the next snapshot? In summary, I see a lot of differences but no benefits. Changing to Maven would mean big changes along with some disruption. For the community to make those changes and accept that disruption there needs to be something in return. So far, I haven't seen anything that I would class as a benefit to the community (e.g. faster build process, simpler releases, fewer bugs, etc.). You see features where I see benefits of the features, asking the same question again and again shows your hate, and probably you hate me too, because I love Maven. No problem, you'll lose at some point :-D Antonio Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Hello, 2011/12/18 jean-frederic clere jfcl...@gmail.com: On 12/17/2011 07:55 PM, Mark Thomas wrote: Personally, I am of the view If it ain't broke, don't fix it. If there was something we would gain by switching to Maven then I'd be interested but given we have an established build process with Ant that a number of committers are familiar with and that I'm not aware of any benefits of moving to Maven then I don't see any compelling reason to switch. Using Maven would allow us to remove build.properties.default and download task that information would go in pom.xml. We can cut Tomcat in module more easily. The other thing is that Maven seems a more active project that Ant so we new feature easy and most IDE allow to import Maven project in IDE workspace. The problem of Maven is that we have to change the structure of our repository I think that the only problem. I have started something here [1] which doesn't change the structure. in tc7, just try mvn clean install -f maven/pom.xml (maven artifacts will be installed) BTW it's only a workaround to not change the structure and certainly doesn't fix any issue with ide (and btw there are a lot things to fix in this test) I have started that but not continuing effort due to lack of interest. It was really a start to produce maven artifacts needed by maven plugin and was more easy to test with SNAPSHOTs build for me. The question regarding changing build system is complicated: as you tomcat core devs prefers ant why moving ? At least for introducing more modularity, why rebuilding everything every time ( what is the need to always rebuild jdbc pool module whereas nothing has changed: this module could have an independent release cycle as it's a library which can be used outside of tomcat container). As the embed api in 7 is pretty cool and available in maven repositories, I'm sure more and more maven users will use it. So using maven could be gain here, as hackers/users will probably want to try provide patch (fixes or new feature) and without a maven build they probably won't do it... BTW if you decide to do/change something, as I have a bit of maven knowledge, let me know if I can help. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] https://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/maven/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
You see features where I see benefits of the features, asking the same question again and again shows your hate, and probably you hate me too, because I love Maven. No problem, you'll lose at some point :-D Using Maven for Tomcat has been many times discussed here, each time with a no go. Consensus was, it works for Ant, why should we change ? There is many reasons to use Maven instead of Ant : * Better startup bootstrap for new comers, mvn package won't require hack in build.properties, it just works out of the box. * Parts of Tomcat, like JDBC POOL could be turned in modules and so have a different lifecycle, ie release more often. * Easier deployment on Artifact Repositories (like Nexus) * Better team-up with others Apache projects, like OpenEJB, who use Tomcat as part of their package process Majority of major ASF projects are now using Maven and they can't all be wrong. So I still didn't understand why there is still such veto on using a de-facto standard like Maven, widely used in companies and also ASF. Sometimes ago, I heard, let's do a proposal. Olivier did it some weeks ago and I don't see many positive feedbacks. He even provided a hackhish pom so Ant and Maven approach could co-exist. We hear more and more ASF is conservative and sometimes slow to adopt new stuff (cf: git discussion) and I should sadly admit, it's still case for Tomcat. There is here a real opportunity to to make them lie. Cheers - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 18 December 2011 18:03, Phil Steitz phil.ste...@gmail.com wrote: On 12/17/11 11:42 AM, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:35, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Ok then using Nexus makes sense only if you are going to use Maven for all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you switch to pure Maven build process? :-D (Joking, but not too much) Yeah, that isn't going to happen :) I've seen way to much pain and grief with Maven on the Commons list to ever want to even think about converting the Tomcat build process to Maven. Commons? That's strange, they are only libraries. Probably they never had cringe-mode-off / a Maven wizard like me cringe-mode-on /. We have several maven committers on the PMC and have been using maven since the 1.x days. One thing we have learned is that maven builds require regular care and feeding. We are on version 23 of the Commons Parent pom. One That's partly due to Maven, but quite a few of those changes are due to new requirements, and updated plugins etc. Having a shared parent pom means more attention has to be paid to it and less to the component poms. So I don't think that's an entirely fair statistic. But I do agree that fixing Maven issues is generally a lot harder than fixing Ant issues. statistic that I have often thought would be interesting to look at is how much time (maybe proxied by number of metadata commits) is spent maintaining maven vs Ant builds. I wonder if on net maven saves time? The tomcat Ant build has been relatively stable compared to the maven projects I know. Could be I am wrong, but I bet tomcat has overall spent less time fussing with its build than the average ASF maven project. In Commons, our success getting to periods of stability (we are between stable points now) has depended on having multiple deeply maven-knowledgeable people prepared to do the work to keep component builds up to date with maven, ASF/Sonatype infrastructure and plugin changes. If there are several tomcat committers willing to step up to do this, then I am sure you can get it to work. Otherwise, you are likely better off staying with Ant. I'm inclined to agree here. I think Commons is somewhat different as it has many small components independently released. Maven enforces some conventions which mean the build processes tend to be similar across projects. Ant is more flexible and it would take a fair amount of work to ensure that all Commons components used standardised Ant build targets. Also Common components are libraries that are often consumed by other Maven projects. Tomcat is mainly a stand-alone download. I don't particularly like Maven - there's far too much built-in magic, which is not always properly explained - but it does have benefits in standardisation and (some aspects of its) dependency management. Phil Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if I can change this situation. I already did it for Velocity (using SVN). The only difficulty is the website. Antonio - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 19 December 2011 08:36, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. So standardization is no benefit? Do you mean that an external developer, that sees a common project structure that can start working on it easily, is not a benefit? 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. Do you think that having a single source tree and letting Ant script reconstruct in some non-obvious way the jars, is a benefit? The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Checkstyle checks unwanted *imports* not dependencies. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. Real modularity means: one source directory - one jar. In other cases, it is not obvious. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? The benefit is that the pom.xml is similar to other projects. After you see a kind of project, you see almost them all. 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? See above. 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? You don't need to maintain a build script, but only use a plugin. Most of the time, it's just the matter of including it. 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). Does ant release tag automatically and prepare for the next snapshot? AIUI, the Maven release plugin temporarily changes the trunk SVN to drop the -SNAPSHOT suffix, merely in order to create the new tag. This means that concurrent builds (e.g. in a CI) may pick up what appears to be a release version, when in fact it is not. For me, that is broken (and unsafe) behaviour, as it requires additional measures to perform it safely. In summary, I see a lot of differences but no benefits. Changing to Maven would mean big changes along with some disruption. For the community to make those changes and accept that disruption there needs to be something in return. So far, I haven't seen anything that I would class as a benefit to the community (e.g. faster build process, simpler releases, fewer bugs, etc.). You see features where I see benefits of the features, asking the same question again and again shows your hate, and probably you hate me too, because I love Maven. No problem, you'll lose at some point :-D Antonio Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/19 sebb seb...@gmail.com On 19 December 2011 08:36, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. So standardization is no benefit? Do you mean that an external developer, that sees a common project structure that can start working on it easily, is not a benefit? 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. Do you think that having a single source tree and letting Ant script reconstruct in some non-obvious way the jars, is a benefit? The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Checkstyle checks unwanted *imports* not dependencies. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. Real modularity means: one source directory - one jar. In other cases, it is not obvious. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? The benefit is that the pom.xml is similar to other projects. After you see a kind of project, you see almost them all. 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? See above. 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? You don't need to maintain a build script, but only use a plugin. Most of the time, it's just the matter of including it. 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). Does ant release tag automatically and prepare for the next snapshot? AIUI, the Maven release plugin temporarily changes the trunk SVN to drop the -SNAPSHOT suffix, merely in order to create the new tag. This means that concurrent builds (e.g. in a CI) may pick up what appears to be a release version, when in fact it is not. For me, that is broken (and unsafe) behaviour, as it requires additional measures to perform it safely. You are right, please open a JIRA issue for this, for example a solution would be to change the version inside the tag. I believe that this operation is done this way for backwards compatibility with CVS. However you must admit that the time taken for this operation is small (commit, tag, commit again). You must be *very unlucky°. Antonio
RE: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
From: Antonio Petrelli [mailto:antonio.petre...@gmail.com] Subject: Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central) Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. I have to strongly agree with Mark here. Having the single source tree has made problem analysis and research much, much simpler. Reverting to the multiple trees just to satisfy Maven's one-size-fits-none philosophy would be a major step backwards. Mladen's earlier comments are spot-on. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 19 December 2011 14:16, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/12/19 sebb seb...@gmail.com On 19 December 2011 08:36, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. So standardization is no benefit? Do you mean that an external developer, that sees a common project structure that can start working on it easily, is not a benefit? 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. Do you think that having a single source tree and letting Ant script reconstruct in some non-obvious way the jars, is a benefit? The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Checkstyle checks unwanted *imports* not dependencies. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. Real modularity means: one source directory - one jar. In other cases, it is not obvious. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? The benefit is that the pom.xml is similar to other projects. After you see a kind of project, you see almost them all. 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? See above. 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? You don't need to maintain a build script, but only use a plugin. Most of the time, it's just the matter of including it. 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). Does ant release tag automatically and prepare for the next snapshot? AIUI, the Maven release plugin temporarily changes the trunk SVN to drop the -SNAPSHOT suffix, merely in order to create the new tag. This means that concurrent builds (e.g. in a CI) may pick up what appears to be a release version, when in fact it is not. For me, that is broken (and unsafe) behaviour, as it requires additional measures to perform it safely. You are right, please open a JIRA issue for this, for example a solution I thought I had, but could not find it so created http://jira.codehaus.org/browse/MRELEASE-721 would be to change the version inside the tag. I believe that this operation is done this way for backwards compatibility with CVS. However you must admit that the time taken for this operation is small (commit, tag, commit again). You must be *very unlucky°. Not necessarily, some CIs build on each change. If there is a network glitch after the first commit, there would be a potentially large time window for problems to occur. AFAIK the temporary change to the version is not the only change that is made to trunk. Antonio - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/19 sebb seb...@gmail.com: On 19 December 2011 14:16, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/12/19 sebb seb...@gmail.com On 19 December 2011 08:36, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. So standardization is no benefit? Do you mean that an external developer, that sees a common project structure that can start working on it easily, is not a benefit? 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. Do you think that having a single source tree and letting Ant script reconstruct in some non-obvious way the jars, is a benefit? The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Checkstyle checks unwanted *imports* not dependencies. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. Real modularity means: one source directory - one jar. In other cases, it is not obvious. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? The benefit is that the pom.xml is similar to other projects. After you see a kind of project, you see almost them all. 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? See above. 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? You don't need to maintain a build script, but only use a plugin. Most of the time, it's just the matter of including it. 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). Does ant release tag automatically and prepare for the next snapshot? AIUI, the Maven release plugin temporarily changes the trunk SVN to drop the -SNAPSHOT suffix, merely in order to create the new tag. This means that concurrent builds (e.g. in a CI) may pick up what appears to be a release version, when in fact it is not. For me, that is broken (and unsafe) behaviour, as it requires additional measures to perform it safely. You are right, please open a JIRA issue for this, for example a solution I thought I had, but could not find it so created http://jira.codehaus.org/browse/MRELEASE-721 would be to change the version inside the tag. I believe that this operation is done this way for backwards compatibility with CVS. However you must admit that the time taken for this operation is small (commit, tag, commit again). You must be *very unlucky°. you are still free to use a rc branch release mode. When you want to release just create branch from where you want to release and people can continue to hack in trunk or in the branch you wanted to cut a release. btw not sure this discussion is related to this thread. Not necessarily, some CIs build on each change. If there is a network glitch after the first commit, there would be a potentially large
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/19 Caldarale, Charles R chuck.caldar...@unisys.com From: Antonio Petrelli [mailto:antonio.petre...@gmail.com] Subject: Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central) Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. I have to strongly agree with Mark here. Having the single source tree has made problem analysis and research much, much simpler. Reverting to the multiple trees just to satisfy Maven's one-size-fits-none philosophy would be a major step backwards. Mladen's earlier comments are spot-on. This is your opinion Charles. Others (like me) see it as a complete mess. I've seen things like one source directory and an Ant build file that creates war, ear, jnlp client package. Moreover, a good IDE saves your analysis time too. Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
+1. But I'm no fan of maven to begin with. -- Ian - Reply message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Developers List dev@tomcat.apache.org Subject: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central) Date: Mon, Dec 19, 2011 09:41 I have to strongly agree with Mark here. Having the single source tree has made problem analysis and research much, much simpler. Reverting to the multiple trees just to satisfy Maven's one-size-fits-none philosophy would be a major step backwards. Mladen's earlier comments are spot-on.
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 18/12/2011 08:37, Mladen Turk wrote: On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I was wondering if someone would mention Gradle. If there's a build tool shootout to be had, Gradle should get fair consideration. p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 06:12 PM, Pid wrote: On 18/12/2011 08:37, Mladen Turk wrote: On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I was wondering if someone would mention Gradle. If there's a build tool shootout to be had, Gradle should get fair consideration. Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. E.g I know that Hibernate switched from Maven to Gradle just because maven But then we are back at original question. What's the benefit and do we have a problem that cannot be done using existing technology? Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. E.g I know that Hibernate switched from Maven to Gradle just because maven Why not. BTW, how many projects moved from Maven to Gradle in JBoss ? But then we are back at original question. What's the benefit and do we have a problem that cannot be done using existing technology? Why using another technology ? Damn't, that's a question I would expect everywhere except on an ASF developer list. Advantages to use Maven have been mentioned many time on tomcat-dev, and I recalled a few on this thread. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. Amount of work we invest in build.xml is negligible compared to the rest of the codebase, and I expect maven will provide such environment. If not, meaning we would need a couple of developers hacking pom's all the time, then a big -1. Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. To repeat.. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script underhttps://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19 david jencks On Dec 19, 2011, at 10:20 AM, Mladen Turk wrote: On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. Amount of work we invest in build.xml is negligible compared to the rest of the codebase, and I expect maven will provide such environment. If not, meaning we would need a couple of developers hacking pom's all the time, then a big -1. Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 19/12/2011 18:47, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. I'm curious. What are the benefits of doing this over using the JARs that Tomcat already publishes to Maven central? Is there something wrong / missing with those JARs? If so, it can probably be fixed. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. How does building with Maven encourage interaction with other communities over and above the interaction we see via publishing the JARS to Maven central that we already publish? To repeat.. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script underhttps://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19 If we switch, I'm sure that that will be useful. What I have yet to see, is a good reason to switch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 19/12/2011 08:36, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. So standardization is no benefit? Do you mean that an external developer, that sees a common project structure that can start working on it easily, is not a benefit? I agree that being able to start working on something easily is a benefit. Where we disagree is how important standardisation and Maven helps. Maven may add standardisation but it also adds complexity. Too much happens under the hood for my liking. You need a much better understanding of the tool to figure out what is going on. I think that makes it harder to get started than the current Ant script. I suspect we just aren't going to agree on this since one's view will change depending on how well one understands Mavem. You understand it very well. I understand it hardly at all. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. Do you think that having a single source tree and letting Ant script reconstruct in some non-obvious way the jars, is a benefit? A single source tree has been a huge benefit. The code is much easier to work with. I'm happy to pay the price of the way the JARs are created to be able to work with a single source tree. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Checkstyle checks unwanted *imports* not dependencies. Agreed, but they are equivalent as makes no difference when talking about dependencies between the JARs (as I was). Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. Real modularity means: one source directory - one jar. In other cases, it is not obvious. Again, what is the benefit? 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? The benefit is that the pom.xml is similar to other projects. After you see a kind of project, you see almost them all. As above, similar but in my view more complex. I suspect how comfortable you are with Maven determines which you think is best and not everyone has your level of skill with Maven. 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? See above. Ditto. 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? You don't need to maintain a build script, but only use a plugin. Most of the time, it's just the matter of including it. My view of the Commons experience is that it often is not that simple, particularly when plug-ins are updated. 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). Does ant release tag automatically and prepare for the next snapshot? No. But it could easily if we wanted to. Personally, again based on what I have seen in Commons, I'd rather keep the manual control. A lot of my views of Maven have been coloured by what I have seen Commons components go through. The Maven release process seems to be fraught with problems. When compared to the current
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hi, i agree on the fact maven is technically more complicated than an ant script but let say you know both maven and ant, your ant script is very complicated to do almost nothing useful. (ok i prefer maven ;)). For newcomers i think it is important. Maven stuff can be almost hidden by a good IDE, complicated ant script can't be hidden by an IDE. Well as said earlier it can be a troll so i'll not speak about it more. What i wanted to add is tomcat starts to be widely used by othes projects (i particularly think of OpenEJB) and maven is almost everywhere used (OpenEJB, Geronimo, Siwpas...). So another question is do you want to be more open to other communities. - Romain 2011/12/19 Mark Thomas ma...@apache.org On 19/12/2011 08:36, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. So standardization is no benefit? Do you mean that an external developer, that sees a common project structure that can start working on it easily, is not a benefit? I agree that being able to start working on something easily is a benefit. Where we disagree is how important standardisation and Maven helps. Maven may add standardisation but it also adds complexity. Too much happens under the hood for my liking. You need a much better understanding of the tool to figure out what is going on. I think that makes it harder to get started than the current Ant script. I suspect we just aren't going to agree on this since one's view will change depending on how well one understands Mavem. You understand it very well. I understand it hardly at all. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. Sincerely, this is the worst thing that you have made. Do you think that having a single source tree and letting Ant script reconstruct in some non-obvious way the jars, is a benefit? A single source tree has been a huge benefit. The code is much easier to work with. I'm happy to pay the price of the way the JARs are created to be able to work with a single source tree. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Checkstyle checks unwanted *imports* not dependencies. Agreed, but they are equivalent as makes no difference when talking about dependencies between the JARs (as I was). Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. Real modularity means: one source directory - one jar. In other cases, it is not obvious. Again, what is the benefit? 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? The benefit is that the pom.xml is similar to other projects. After you see a kind of project, you see almost them all. As above, similar but in my view more complex. I suspect how comfortable you are with Maven determines which you think is best and not everyone has your level of skill with Maven. 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? See above. Ditto. 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? You don't need to maintain a build script, but only use a plugin. Most of the time, it's just the matter of including it. My view of the Commons experience is that it often is
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 07:47 PM, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. And that relates to this thread in exactly which way? You guys did that for Geronimo, fine, great, super. Here we speak that we should replace entire Tomcat build system with maven, meaning, multiple arches, creating windows installer, etc. I don't see any of those in Geronimo. All I'm saying, if you can do it, you're welcome. I'd like to see 'ant release' using 'mvn release' before someone breaks trunk. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Here we speak that we should replace entire Tomcat build system with maven, meaning, multiple arches, creating windows installer, etc. I don't see any of those in Geronimo. Why no do it step by step and produce with Maven what's produced today by Ant ? All I'm saying, if you can do it, you're welcome. I'd like to see 'ant release' using 'mvn release' before someone breaks trunk. I suggest discuss with Olivier who do a good works on Mavenisation of Tomcat. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
There is a big part of tomcat which doesn't need maven because it doesn't need to be standard (the installers are a great example). I spoke about the common part which is today not obvious because of the false modularity of the project. - Romain 2011/12/19 Mladen Turk mt...@apache.org On 12/19/2011 07:47 PM, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. And that relates to this thread in exactly which way? You guys did that for Geronimo, fine, great, super. Here we speak that we should replace entire Tomcat build system with maven, meaning, multiple arches, creating windows installer, etc. I don't see any of those in Geronimo. All I'm saying, if you can do it, you're welcome. I'd like to see 'ant release' using 'mvn release' before someone breaks trunk. Regards -- ^TM --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 19/12/2011 09:42, Henri Gomez wrote: There is many reasons to use Maven instead of Ant : * Better startup bootstrap for new comers, mvn package won't require hack in build.properties, it just works out of the box. No it won't. At least not until Eclipse publish the JDT complier JAR to Maven Central and the last few times I looked the only versions published were old ones it they looked to have been published by third parties. We could take on publishing the compiler to Maven Central but it would be more work than the current process. * Parts of Tomcat, like JDBC POOL could be turned in modules and so have a different lifecycle, ie release more often. We tried releasing JDBC pool as a separate component and it failed miserably. I recall many more failed release votes due to lack of interest than I recall release votes that passed. * Easier deployment on Artifact Repositories (like Nexus) I don't buy that argument. It is as easy to publish to Maven central with the current process as it is to do so if the entire build uses Maven. From a release manager's point of view there is nothing in it. * Better team-up with others Apache projects, like OpenEJB, who use Tomcat as part of their package process I don't see these projects asking us to change our build process. I do see requests for additional artifacts but those are just as easy to produce with either build process. Majority of major ASF projects are now using Maven and they can't all be wrong. Looking at the experience in Commons (that uses Maven), I'd have to say that in my view Tomcat currently has the better release process. So I still didn't understand why there is still such veto on using a de-facto standard like Maven, widely used in companies and also ASF. I don't recall seeing a veto on this. I do see a number of committers that are far from convinced that Maven is the right way to go. Sometimes ago, I heard, let's do a proposal. Olivier did it some weeks ago and I don't see many positive feedbacks. He even provided a hackhish pom so Ant and Maven approach could co-exist. I would say that the lack of feedback indicates the lack of interest. If Olivier's build process made my life easier, I'd use it. It doesn't, so I don't. We hear more and more ASF is conservative and sometimes slow to adopt new stuff (cf: git discussion) and I should sadly admit, it's still case for Tomcat. Lets not re-hash the git discussion here. I agree the ASF is conservative and I think that is a good thing. It is a direct result of our consensus based approach to development. Yes it makes doing something new and radical harder as you have to convince folks that the radical new idea is a good one. But this has always been the case and we have had a process for this for many years [1]. I'm with Mladen on this one. Make a copy of trunk in the sandbox. Do what needs to be done to align with Maven best practices and show us how it is better than what we have at the moment. If someone would like to do the same for gradle or another tool, great. If there are real benefits, I'll vote for it. If it is just different then my preference will be for staying as we are. Mark [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 08:58 PM, Romain Manni-Bucau wrote: There is a big part of tomcat which doesn't need maven because it doesn't need to be standard (the installers are a great example). Installer is just ant exec task with some filtering for getting the versions correctly. We have multiple release artifacts using different compressors having different line endings, so I suppose that would stay with ant as well. I spoke about the common part which is today not obvious because of the false modularity of the project. So it would be ant + maven I suppose. Fine, who's gonna do it and maintain? Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
because developers can't know both? we use both on OpenEJB (ok the ant part is small but it is used through the maven plugin). I don't know if it is because i used more maven than ant but when i checked out tomcat the first time i wondered where was modules (corresponding to jars). I was doing the same with ant. So i don't say use mvn or ant even if IMHO mvn could be a benefit for the community. I just say be consistent with your artifacts. - Romain 2011/12/19 Mladen Turk mt...@apache.org On 12/19/2011 08:58 PM, Romain Manni-Bucau wrote: There is a big part of tomcat which doesn't need maven because it doesn't need to be standard (the installers are a great example). Installer is just ant exec task with some filtering for getting the versions correctly. We have multiple release artifacts using different compressors having different line endings, so I suppose that would stay with ant as well. I spoke about the common part which is today not obvious because of the false modularity of the project. So it would be ant + maven I suppose. Fine, who's gonna do it and maintain? Regards -- ^TM --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 09:13 PM, Romain Manni-Bucau wrote: I don't know if it is because i used more maven than ant but when i checked out tomcat the first time i wondered where was modules (corresponding to jars). OK, this is the first thing I can agree with you. But It has nothing to do with toolkit used. Repository reorganization to match the .jars we produce could be done with or without maven. Also producing jars is just one part of release process. I'm afraid that amount of tasks that either cannot be done by maven, or it would require a huge effort and bunch of custom mojo's is just not worth the effort. But like I said (hate to repeat myself). Anyone is welcome to volunteer and propose a working solution that won't require more work on release tools when making a release compared to the existing system. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 07:47 PM, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. So starting with what is in the geronimo repo, how much work would it to have a mavenized Tomcat? As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. We already publish artifacs, do you need more of them? Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
i needed to dig into tomcat for some bugs regarding TCKs. That's why i needed more. - Romain 2011/12/19 jean-frederic clere jfcl...@gmail.com On 12/19/2011 07:47 PM, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. So starting with what is in the geronimo repo, how much work would it to have a mavenized Tomcat? As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. We already publish artifacs, do you need more of them? Cheers Jean-Frederic --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Thanks for your brevity, Mark On Dec 19, 2011, at 11:24 AM, Mark Thomas wrote: On 19/12/2011 18:47, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. I'm curious. What are the benefits of doing this over using the JARs that Tomcat already publishes to Maven central? Is there something wrong / missing with those JARs? If so, it can probably be fixed. Geronimo originally needed a way we could track to apply patches. I don't know that we have needed any patches recently, but we now need osgi bundles. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. How does building with Maven encourage interaction with other communities over and above the interaction we see via publishing the JARS to Maven central that we already publish? I generally wont work on projects that aren't maven based because the project layout and build system usually takes too long for me to understand to be worth it for the possible contribution I might make. Now that Geronimo has a mavenized tomcat, I can consider working on tomcat problems in the mavenized copy and if I think it's worth the trouble try to generate a patch against the original tomcat source. I think the standardization maven brings makes projects much more friendly to outsiders looking to contribute. thanks david jencks To repeat.. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script underhttps://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19 If we switch, I'm sure that that will be useful. What I have yet to see, is a good reason to switch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/19/2011 09:13 PM, Romain Manni-Bucau wrote: because developers can't know both? Since it seems you are familiar with maven, what is your opinion about maven ant tasks? Seems to me it offers full power of Ant, almost seamless transition, with the option to use maven deploy and dependency tasks where appropriate. Since those tasks look like any other ant task think it could be easily digested by this community. OTOH, we'd still have some dependency issues with JDT, daemon native, tomcat native, so it would be only partial solution, but given that it would effectively behave like extension to our download task I can live with the extra complexity. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Romain Manni-Bucau rmannibu...@gmail.com wrote: i needed to dig into tomcat for some bugs regarding TCKs. That's why i needed more. - Romain What did you need that the published JARs and source JARs didn't give you? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On Dec 19, 2011, at 1:06 PM, jean-frederic clere wrote: On 12/19/2011 07:47 PM, David Jencks wrote: Are you reading the thread? I mentioned dec 17 that geronimo has been maintaining a script for 2+ years that pulls tomcat source out of tomcat svn and puts it in an appropriately structured maven mutli-project build and we've been re-releasing quite a few tomcat versions using this technique. Not sure how this is talk. I've experienced enough hostility over the years from the tomcat community (not necessarily any currently active members) that I'm reluctant to spend more time on this. So starting with what is in the geronimo repo, how much work would it to have a mavenized Tomcat? I did this work and suggested tomcat look at it several years ago, and don't remember all the details, some other people have been maintaining it recently. IIRC the maven projects generate pretty much the same jars as the ant build, possibly plus one more to get around the circular dependencies among the jars. So to generate a maven multimodule project to build the jars, 20 min to configure the script that builds the project, then you have a mavenized tomcat project checked in that builds pretty much the same jars as the ant build. I don't really know what else the ant build generates. As I have said before in previous iterations of this topic, IMO many of the advantages of maven are not for direct development of the project itself (although they certainly exist) but in encouraging interactions with other projects and communities. You won't be able to detect these without actually using maven. We already publish artifacs, do you need more of them? I think the benefit might be more on the order of encouraging people who ask where did this jar come from-- I wanna fix something. For people familiar with maven, there is IMO a much higher barrier to contributing to tomcat than a well-structured maven project. (BTW I must add that I'm delighted that the tomcat community seems much more receptive to outside input than it did several years ago -- community unfriendliness seems to be totally missing now :-) ). thanks david jencks Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 12/17/2011 07:55 PM, Mark Thomas wrote: Personally, I am of the view If it ain't broke, don't fix it. If there was something we would gain by switching to Maven then I'd be interested but given we have an established build process with Ant that a number of committers are familiar with and that I'm not aware of any benefits of moving to Maven then I don't see any compelling reason to switch. Using Maven would allow us to remove build.properties.default and download task that information would go in pom.xml. We can cut Tomcat in module more easily. The other thing is that Maven seems a more active project that Ant so we new feature easy and most IDE allow to import Maven project in IDE workspace. The problem of Maven is that we have to change the structure of our repository I think that the only problem. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/17/2011 09:24 PM, Antonio Petrelli wrote: As requested here is a proposal to move to Maven. I simply cannot understand why some folks have almost religious fascination with Maven. I know many projects that have move from Ant to Maven and are now either switched back or gone to some other solution like Gradle or are in the active process of seeking the alternative. I won't support such a transition at this moment. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 12/17/11 11:42 AM, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:35, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Ok then using Nexus makes sense only if you are going to use Maven for all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you switch to pure Maven build process? :-D (Joking, but not too much) Yeah, that isn't going to happen :) I've seen way to much pain and grief with Maven on the Commons list to ever want to even think about converting the Tomcat build process to Maven. Commons? That's strange, they are only libraries. Probably they never had cringe-mode-off / a Maven wizard like me cringe-mode-on /. We have several maven committers on the PMC and have been using maven since the 1.x days. One thing we have learned is that maven builds require regular care and feeding. We are on version 23 of the Commons Parent pom. One statistic that I have often thought would be interesting to look at is how much time (maybe proxied by number of metadata commits) is spent maintaining maven vs Ant builds. I wonder if on net maven saves time? The tomcat Ant build has been relatively stable compared to the maven projects I know. Could be I am wrong, but I bet tomcat has overall spent less time fussing with its build than the average ASF maven project. In Commons, our success getting to periods of stability (we are between stable points now) has depended on having multiple deeply maven-knowledgeable people prepared to do the work to keep component builds up to date with maven, ASF/Sonatype infrastructure and plugin changes. If there are several tomcat committers willing to step up to do this, then I am sure you can get it to work. Otherwise, you are likely better off staying with Ant. Phil Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if I can change this situation. I already did it for Velocity (using SVN). The only difficulty is the website. Antonio - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 17 December 2011 05:19, Phil Steitz phil.ste...@gmail.com wrote: On 12/16/11 12:56 PM, Mark Thomas wrote: All, There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus Personally, my only requirements are: a) that the JARs reach Maven Central b) publishing is as simple as running a single script I would be very interested to know if anyone has figured out a way to fully script Nexus. AFAIK, Nexus requires that you use the GUI I think that's the main advantage or Nexus - makes it difficult to accidentally release files. This happened at least once in Commons before we started using Nexus. AIUI there is a REST interface which could be scripted if one could find the docs. But I think it would negate one of the main benefits if this allowed releases to be published to Maven Central automatically. and also (sic) store credentials in a plaintext file. Maybe someone AFAIK that's not true - or at least if it is, that's due to using Maven deploy, rather than Nexus, which is not directly involved in the upload. has figured out a way around this. I would be very interested to You can store the master password on a USB stick for Maven to use. Or you could use something like a TrueCrypt container file. learn this so we can improve the not-quite-functional process that we have been fumbling with in Commons [1]. FWIW, my NSHO is that if you have a working script that produces good artifacts that can be scpd to central, there is no reason to bring in proprietary software, plaintext credential files or GUI steps. Phil [1] http://wiki.apache.org/commons/UsingNexus I don't particularly care about the details. As long as all I have to do is run a script and the JARs end up in Maven Central I'm happy. I know option 1 works and I assume 2 will work the same way. Therefore I have no preference for either approach. Does anyone else have any requirements / views that would suggest one approach is better than the other? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On Dec 17, 2011, at 6:44 AM, sebb seb...@gmail.com wrote: On 17 December 2011 05:19, Phil Steitz phil.ste...@gmail.com wrote: On 12/16/11 12:56 PM, Mark Thomas wrote: All, There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus Personally, my only requirements are: a) that the JARs reach Maven Central b) publishing is as simple as running a single script I would be very interested to know if anyone has figured out a way to fully script Nexus. AFAIK, Nexus requires that you use the GUI I think that's the main advantage or Nexus - makes it difficult to accidentally release files. This happened at least once in Commons before we started using Nexus. Only via the release plugin and not following the documented process at the time. Adding GUI steps and more mysterious software *decreases* control. AIUI there is a REST interface which could be scripted if one could find the docs. But I think it would negate one of the main benefits if this allowed releases to be published to Maven Central automatically. Which the simple rsync setup that tomcat and some Commons holdouts still use does in a much simpler and more transparent way. and also (sic) store credentials in a plaintext file. Maybe someone AFAIK that's not true - or at least if it is, that's due to using Maven deploy, rather than Nexus, which is not directly involved in the upload. has figured out a way around this. I would be very interested to You can store the master password on a USB stick for Maven to use. Or you could use something like a TrueCrypt container file. Thats what I meant above. Phil learn this so we can improve the not-quite-functional process that we have been fumbling with in Commons [1]. FWIW, my NSHO is that if you have a working script that produces good artifacts that can be scpd to central, there is no reason to bring in proprietary software, plaintext credential files or GUI steps. Phil [1] http://wiki.apache.org/commons/UsingNexus I don't particularly care about the details. As long as all I have to do is run a script and the JARs end up in Maven Central I'm happy. I know option 1 works and I assume 2 will work the same way. Therefore I have no preference for either approach. Does anyone else have any requirements / views that would suggest one approach is better than the other? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
2011/12/16 Mark Thomas ma...@apache.org There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus In my experience in Tiles releases, the only problem we had with scp + simple copy (we did not use rsync) is that this process breaks Maven metadata. I try to explain myself. If you release to a staging directory, the Maven metadata (containg info about previous releases) are not there, so they are created from scratch. So, after releasing in the staging directory and voting, the copy method simply overwrite the old metadata with the new one (remember, *without the old versions*). So in the end, we needed to use the Maven stage plugin (deprecated), that: * downloads the staged artifacts; * reuploads them to the final destination. Inside Nexus, you simply promote the staged repository, without the problem of downloading and uploading again. Antonio
Re: Publishing process for JARs for Maven Central
On 17/12/2011 18:08, Antonio Petrelli wrote: 2011/12/16 Mark Thomas ma...@apache.org There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus In my experience in Tiles releases, the only problem we had with scp + simple copy (we did not use rsync) is that this process breaks Maven metadata. I try to explain myself. If you release to a staging directory, the Maven metadata (containg info about previous releases) are not there, so they are created from scratch. So, after releasing in the staging directory and voting, the copy method simply overwrite the old metadata with the new one (remember, *without the old versions*). So in the end, we needed to use the Maven stage plugin (deprecated), that: * downloads the staged artifacts; * reuploads them to the final destination. That is not an issue. Tomcat doesn't release to a staging repo first. The Maven artefact release is only done after the release vote has passed. If you look at the Tomcat 7 metadata you'll see that all versions are present. Inside Nexus, you simply promote the staged repository, without the problem of downloading and uploading again. That is not a problem with the scp+rsync process used by the Tomcat project. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:08, Antonio Petrelli wrote: 2011/12/16 Mark Thomas ma...@apache.org There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus In my experience in Tiles releases, the only problem we had with scp + simple copy (we did not use rsync) is that this process breaks Maven metadata. I try to explain myself. If you release to a staging directory, the Maven metadata (containg info about previous releases) are not there, so they are created from scratch. So, after releasing in the staging directory and voting, the copy method simply overwrite the old metadata with the new one (remember, *without the old versions*). So in the end, we needed to use the Maven stage plugin (deprecated), that: * downloads the staged artifacts; * reuploads them to the final destination. That is not an issue. Tomcat doesn't release to a staging repo first. The Maven artefact release is only done after the release vote has passed. If you look at the Tomcat 7 metadata you'll see that all versions are present. Inside Nexus, you simply promote the staged repository, without the problem of downloading and uploading again. That is not a problem with the scp+rsync process used by the Tomcat project. Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. Antonio
Re: Publishing process for JARs for Maven Central
On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 16/12/2011 19:56, Mark Thomas wrote: All, There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus Personally, my only requirements are: a) that the JARs reach Maven Central b) publishing is as simple as running a single script I don't particularly care about the details. As long as all I have to do is run a script and the JARs end up in Maven Central I'm happy. I know option 1 works and I assume 2 will work the same way. Therefore I have no preference for either approach. Does anyone else have any requirements / views that would suggest one approach is better than the other? More info from [1]. 1 means running a single script (after the release vote has passed) 2 means running a single script (before or after the release vote) and then a couple of clicks in Nexus to promote the JARs once the release vote passes. Nexus pros: The Maven artefacts can be available sooner since we can upload them while the release vote is running. Nexus cons: What was a single step to release the Maven JARs is now multiple steps. I think I am still neutral on this. Jean-Frederic, what was your motivation for moving Tomcat to Nexus? Mark [1] https://issues.apache.org/jira/browse/INFRA-4162 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Ok then using Nexus makes sense only if you are going to use Maven for all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you switch to pure Maven build process? :-D (Joking, but not too much) Antonio
Re: Publishing process for JARs for Maven Central
On 17/12/2011 18:35, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Ok then using Nexus makes sense only if you are going to use Maven for all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you switch to pure Maven build process? :-D (Joking, but not too much) Yeah, that isn't going to happen :) I've seen way to much pain and grief with Maven on the Commons list to ever want to even think about converting the Tomcat build process to Maven. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:35, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Ok then using Nexus makes sense only if you are going to use Maven for all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you switch to pure Maven build process? :-D (Joking, but not too much) Yeah, that isn't going to happen :) I've seen way to much pain and grief with Maven on the Commons list to ever want to even think about converting the Tomcat build process to Maven. Commons? That's strange, they are only libraries. Probably they never had cringe-mode-off / a Maven wizard like me cringe-mode-on /. Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if I can change this situation. I already did it for Velocity (using SVN). The only difficulty is the website. Antonio
Re: Publishing process for JARs for Maven Central
On 17/12/2011 18:42, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:35, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Ok then using Nexus makes sense only if you are going to use Maven for all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you switch to pure Maven build process? :-D (Joking, but not too much) Yeah, that isn't going to happen :) I've seen way to much pain and grief with Maven on the Commons list to ever want to even think about converting the Tomcat build process to Maven. Commons? That's strange, they are only libraries. Probably they never had cringe-mode-off / a Maven wizard like me cringe-mode-on /. Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if I can change this situation. I already did it for Velocity (using SVN). The only difficulty is the website. Personally, I am of the view If it ain't broke, don't fix it. If there was something we would gain by switching to Maven then I'd be interested but given we have an established build process with Ant that a number of committers are familiar with and that I'm not aware of any benefits of moving to Maven then I don't see any compelling reason to switch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:42, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:35, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Ok then using Nexus makes sense only if you are going to use Maven for all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you switch to pure Maven build process? :-D (Joking, but not too much) Yeah, that isn't going to happen :) I've seen way to much pain and grief with Maven on the Commons list to ever want to even think about converting the Tomcat build process to Maven. Commons? That's strange, they are only libraries. Probably they never had cringe-mode-off / a Maven wizard like me cringe-mode-on /. Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if I can change this situation. I already did it for Velocity (using SVN). The only difficulty is the website. Personally, I am of the view If it ain't broke, don't fix it. If there was something we would gain by switching to Maven then I'd be interested but given we have an established build process with Ant that a number of committers are familiar with and that I'm not aware of any benefits of moving to Maven then I don't see any compelling reason to switch. Using Maven has several benefits (standardization of structure, lots of reusable plugins, supported by major IDEs), but, somehow, they still don't convince hardcode Ant believers. I prefer speaking with facts and I love doing Maven reconstructions. Since Apache lets us use Git, though in a read-only way, and since I use and love Tomcat, I think that it's worth a try. Antonio
Re: Publishing process for JARs for Maven Central
On 17/12/2011 19:10, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org Personally, I am of the view If it ain't broke, don't fix it. If there was something we would gain by switching to Maven then I'd be interested but given we have an established build process with Ant that a number of committers are familiar with and that I'm not aware of any benefits of moving to Maven then I don't see any compelling reason to switch. Using Maven has several benefits (standardization of structure, lots of reusable plugins, supported by major IDEs), Those are features, not benefits. If you can demonstrate how switching to Maven will be better, then I am all ears. So far Maven just looks different rather than better with the disadvantage (for me at least) that Maven is unfamiliar whereas Ant is familiar. There needs to be an incentive to go up the Maven learning curve and I haven't seen one yet. I prefer speaking with facts and I love doing Maven reconstructions. Since Apache lets us use Git, though in a read-only way, and since I use and love Tomcat, I think that it's worth a try. You are, of course, free to take a look at this. It might be more productive to try and make the case for Maven before doing that work. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
As requested here is a proposal to move to Maven. 2011/12/17 Mark Thomas ma...@apache.org Using Maven has several benefits (standardization of structure, lots of reusable plugins, supported by major IDEs), Those are features, not benefits. The standardization of structure is not a feature, but a constraint. When you use Maven *the right way* you ought to follow a well standardized structure. You are, of course, free to take a look at this. It might be more productive to try and make the case for Maven before doing that work Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Antonio
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). In summary, I see a lot of differences but no benefits. Changing to Maven would mean big changes along with some disruption. For the community to make those changes and accept that disruption there needs to be something in return. So far, I haven't seen anything that I would class as a benefit to the community (e.g. faster build process, simpler releases, fewer bugs, etc.). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
I'll try to keep it short because I really don't want to spend time re-beating this dead horse. The last time I looked a couple years ago the jars constructed out of the single source tree could not be compiled separately in any order. I was told this wasn't a problem, at which point I realized discussion was useless. Maven prevents problems like this through the project structure. If this situation is not a problem to the tomcat community, then the other possible benefits of using maven are not likely to be interesting either. thanks david jencks On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). In summary, I see a lot of differences but no benefits. Changing to Maven would mean big changes along with some disruption. For the community to make those changes and accept that disruption there needs to be something in return. So far, I haven't seen anything that I would class as a benefit to the community (e.g. faster build process, simpler releases, fewer bugs, etc.). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
2011/12/17 Antonio Petrelli antonio.petre...@gmail.com: If you release to a staging directory, the Maven metadata (containg info about previous releases) are not there, so they are created from scratch. So, after releasing in the staging directory and voting, the copy method simply overwrite the old metadata with the new one (remember, *without the old versions*). So in the end, we needed to use the Maven stage plugin (deprecated), that: * downloads the staged artifacts; * reuploads them to the final destination. Mark, the above issue mentioned by Antonio is what I think we already encountered with broken maven-metadata.xml. That is https://issues.apache.org/bugzilla/show_bug.cgi?id=52124 More detailed description is in https://issues.sonatype.org/browse/MVNCENTRAL-139 Mark, when you do 7.0 releases, do you scp the maven-metadata.xml file? Do you have all previous releases of 7.0 in your local repository (so that the file is built correctly)? If Nexus allows to prepare new releases without the need to keep old releases around, I am +1 for it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 17/12/2011 21:43, Konstantin Kolinko wrote: 2011/12/17 Antonio Petrelli antonio.petre...@gmail.com: If you release to a staging directory, the Maven metadata (containg info about previous releases) are not there, so they are created from scratch. So, after releasing in the staging directory and voting, the copy method simply overwrite the old metadata with the new one (remember, *without the old versions*). So in the end, we needed to use the Maven stage plugin (deprecated), that: * downloads the staged artifacts; * reuploads them to the final destination. Mark, the above issue mentioned by Antonio is what I think we already encountered with broken maven-metadata.xml. That is https://issues.apache.org/bugzilla/show_bug.cgi?id=52124 More detailed description is in https://issues.sonatype.org/browse/MVNCENTRAL-139 That was a broken Tomcat 6 build process. Tomcat 7 doesn't have that problem (and now, neither does 6). Granted using Nexus would have avoided that issue but it has taken 5 years (since the 6.0.0 tag) for someone to complain. That suggests to me the issue is minor. Mark, when you do 7.0 releases, do you scp the maven-metadata.xml file? I assume that the file gets correctly generated automatically. Do you have all previous releases of 7.0 in your local repository (so that the file is built correctly)? No. I have 7.0.11 - 7.0.23 (mainly because I haven't cleaned it out in a while). It looks like the build process grabs a copy of the metadata from the remote repo, updates it to add the new version and then uploads the updated file. If Nexus allows to prepare new releases without the need to keep old releases around, I am +1 for it. As far as I can tell, Nexus and the scp+rsync process are the same in this regard. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 17/12/2011 21:12, David Jencks wrote: I'll try to keep it short because I really don't want to spend time re-beating this dead horse. The last time I looked a couple years ago the jars constructed out of the single source tree could not be compiled separately in any order. I was told this wasn't a problem, at which point I realized discussion was useless. I just did a check with JarAnalyzer and we still have circular dependency issues with catalina.jar, catalina-ha.jar and catalina-tribes.jar I haven't looked in the archives for the previous discussion and I can't remember what my views were then - probably completely opposite to now :). I wouldn't class it as a problem (I am happy to live with this) but I'm happy to take a look to see if there is an easy fix and apply the fix in that case. Maven prevents problems like this through the project structure. If this situation is not a problem to the tomcat community, then the other possible benefits of using maven are not likely to be interesting either. The dependencies we really care about are monitored via Checkstyle. If I fix the above issue, I'll add some additional checks so we don't recreate the issue. Mark thanks david jencks On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). In summary, I see a lot of differences but no benefits. Changing to Maven would mean big changes along with some disruption. For the community to make those changes and accept that disruption there needs to be something in return. So far, I haven't seen anything that I would class as a benefit to the community (e.g. faster build process, simpler releases, fewer bugs, etc.). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 17/12/2011 21:59, Mark Thomas wrote: On 17/12/2011 21:12, David Jencks wrote: I'll try to keep it short because I really don't want to spend time re-beating this dead horse. The last time I looked a couple years ago the jars constructed out of the single source tree could not be compiled separately in any order. I was told this wasn't a problem, at which point I realized discussion was useless. I just did a check with JarAnalyzer and we still have circular dependency issues with catalina.jar, catalina-ha.jar and catalina-tribes.jar These have been fixed in trunk and I'll port it to 7.0.x shortly. It looks like a recent clean-up change of mine introduced this so 7.0.x should have been buildable jar by jar for most of its life. There are some other dependencies I want to look into and I may have further commits to clean-up the dependencies shortly. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
I forgot to mention that geronimo has been re-releasing several versions of tomcat built with maven. We have a script to set up a maven multi module project structure and distribute the tomcat source code from tomcat svn into the maven projects. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19 thanks david jencks On Dec 17, 2011, at 1:12 PM, David Jencks wrote: I'll try to keep it short because I really don't want to spend time re-beating this dead horse. The last time I looked a couple years ago the jars constructed out of the single source tree could not be compiled separately in any order. I was told this wasn't a problem, at which point I realized discussion was useless. Maven prevents problems like this through the project structure. If this situation is not a problem to the tomcat community, then the other possible benefits of using maven are not likely to be interesting either. thanks david jencks On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: On 17/12/2011 20:24, Antonio Petrelli wrote: Ok, let's do it again :-D 1. Standardization. Maven strongly encourages to use a standardized structure. The source should go into src/main/java, the resources in src/main/resources etc. You can change it, but this is discouraged. With Ant you always do things differently for different projects. What benefit is this to the Tomcat community? I see a change, but no benefit. 2. Modularization. Separation between modules is strong, i.e. one jar-one source directory. In the case of Tomcat, there is a big big trouble: one single big source directory. Separating them will be one of the most important step to do. Why is that an issue? Switching to a single source tree was one of the best changes we ever made. It has been much easier to manage than the multiple source trees we had in the past. The dependencies are known and we have checks in place (via Checkstyle) to ensure that unwanted dependencies are not added. Again, what is the benefit here to the Tomcat community? There has been some interest but very little activity towards greater modularity. If there was more interest in increasing modularity then there might be a case for this but given Tomcat's remit of implementing the Servlet and JSP specs there is very little that could be made modular / optional. Jasper and EL are already optional (well, they can be removed) and pretty much everything else is required by the Servlet spec. 3. Metadata-driven process. The build process is driven by metadata (where the source is? where should I deploy it?) and not by commands (compile the source that is in that point, deploy it in that repository) Again, how does this benefit the Tomcat community? 4. POMs are (almost) universal. Projects of the same kind have almost the same content.. How does this benefit the Tomcat community? 5. Plug-ins do generically what pieces of Ant's script do specifically. For example take the Maven assembly plugin: via a descriptor you obtain a zip file to distribute. That sounds like just a different way of doing things. What is the benefit? 6. When all the metadata is in place, the release process is a matter of launching: mvn release:prepare and mvn release:perform Right now the release process is: ant release followed by scp / ftp / 'take your pick' the files to the right place and that could be added to the script if we really wanted to (but no-one has felt the need to scratch that itch). In summary, I see a lot of differences but no benefits. Changing to Maven would mean big changes along with some disruption. For the community to make those changes and accept that disruption there needs to be something in return. So far, I haven't seen anything that I would class as a benefit to the community (e.g. faster build process, simpler releases, fewer bugs, etc.). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 12/17/2011 07:27 PM, Mark Thomas wrote: Jean-Frederic, what was your motivation for moving Tomcat to Nexus? 1 - The good thing in Nexus is that we can check the result of our deploy-release and drop is we screw it (multi upload can fail and we don't know when the mirroring stars). 2 - Users using maven can test easy the jar in staging Nexus repository. 3 - I was looking to fix BZ 52124 a clean way. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Publishing process for JARs for Maven Central
All, There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus Personally, my only requirements are: a) that the JARs reach Maven Central b) publishing is as simple as running a single script I don't particularly care about the details. As long as all I have to do is run a script and the JARs end up in Maven Central I'm happy. I know option 1 works and I assume 2 will work the same way. Therefore I have no preference for either approach. Does anyone else have any requirements / views that would suggest one approach is better than the other? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
