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 Lamy: 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 d<8E>c. 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: 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: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turk 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
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 :
>> On 23/12/2011 12:58, Olivier Lamy wrote:
>>> Hello,
>>>
>>> 2011/12/23 Mark Thomas :
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 ?
> 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: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/23 Mark Thomas :
> On 23/12/2011 12:58, Olivier Lamy wrote:
>> Hello,
>>
>> 2011/12/23 Mark Thomas :
>>> 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 12:58, Olivier Lamy wrote:
> Hello,
>
> 2011/12/23 Mark Thomas :
>> 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)
Hello,
2011/12/23 Mark Thomas :
> 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 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, 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 : > 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 d<8E>c. 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 : >> 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 : >>> On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turk > 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
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)
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 :
> 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 d<8E>c. 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 :
>> 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 :
>>> On 20/12/2011 08:17, Antonio Petrelli wrote:
2011/12/19 Mladen Turk
> 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 unsub
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 d<8E>c. 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 : > 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 : >> On 20/12/2011 08:17, Antonio Petrelli wrote: >>> 2011/12/19 Mladen Turk >>> 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)
On 21/12/2011 22:19, Mladen Turk wrote: > 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. True, but currently we can just do: svn merge -c https://svn.apache.org/repos/asf/tomcat/trunk I don't know if svn is smart enough to be able to continue to do that if we have moved the source around in trunk. That would be a test worth doing. In summary, so far we have: * +ve OSGi bundles could be easier (need to see if we can use the same plug-in via the current Ant script) * -ve merging trunk to 7.0.x could be harder (need to see how smart svn merging is) 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)
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 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: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 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)
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 Thomas: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turk 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)
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 : > On 20/12/2011 08:17, Antonio Petrelli wrote: >> 2011/12/19 Mladen Turk >> >>> 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)
Two cents from a side On Tue, Dec 20, 2011 at 11:21 PM, Sylvain Laurent 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. regards Leon - 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 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)
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)
Another good thing in gradle is its incremental build support. - Romain 2011/12/20 Pid > On 20/12/2011 08:38, Antonio Petrelli wrote: > > 2011/12/19 Pid > > > >> 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/12/2011 08:38, Antonio Petrelli wrote: > 2011/12/19 Pid > >> 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)
2011/12/20 Antonio Petrelli > 2011/12/20 Mark Thomas > >> On 20/12/2011 09:05, Olivier Lamy wrote: >> > 2011/12/20 Antonio Petrelli : >> >> >> 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)
2011/12/20 Mark Thomas > On 20/12/2011 09:05, Olivier Lamy wrote: > > 2011/12/20 Antonio Petrelli : > > >> 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)
On 20/12/2011 09:05, Olivier Lamy wrote: > 2011/12/20 Antonio Petrelli : >> 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)
On 20/12/2011 08:17, Antonio Petrelli wrote: > 2011/12/19 Mladen Turk > >> 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 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)
2011/12/20 Mark Thomas > 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 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 Konstantin Kolinko > 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)
2011/12/20 Antonio Petrelli : > 2011/12/19 Pid > >> 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 Antonio Petrelli : > 2011/12/20 jean-frederic clere > >> On 12/20/2011 09:17 AM, Antonio Petrelli wrote: >> >>> 2011/12/19 Mladen Turk >>> >>> 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.**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/19 Pid > 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 jean-frederic clere > On 12/20/2011 09:17 AM, Antonio Petrelli wrote: > >> 2011/12/19 Mladen Turk >> >> 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.**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 Turk 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)
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)
2011/12/19 David Jencks > 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)
2011/12/19 Mladen Turk > 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)
+1 - Romain 2011/12/20 David Jencks > > 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)
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)
Romain Manni-Bucau 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 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)
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)
i needed to dig into tomcat for some bugs regarding TCKs. That's why i needed more. - Romain 2011/12/19 jean-frederic clere > 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.**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)
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)
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 > 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.**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)
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)
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 > 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.**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)
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)
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 > On 19/12/2011 08:36, Antonio Petrelli wrote: > > 2011/12/17 Mark Thomas > > > >> 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 th
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 > >> 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 h
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)
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 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)
> 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 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)
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)
+1. But I'm no fan of maven to begin with. -- Ian - Reply message - From: "Caldarale, Charles R" To: "Tomcat Developers List" 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)
2011/12/19 Caldarale, Charles R > > 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)
2011/12/19 sebb : > On 19 December 2011 14:16, Antonio Petrelli > wrote: >> 2011/12/19 sebb >> >>> On 19 December 2011 08:36, Antonio Petrelli >>> wrote: >>> > 2011/12/17 Mark Thomas >>> > >>> >> 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
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 19 December 2011 14:16, Antonio Petrelli wrote: > 2011/12/19 sebb > >> On 19 December 2011 08:36, Antonio Petrelli >> wrote: >> > 2011/12/17 Mark Thomas >> > >> >> 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 aft
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)
2011/12/19 sebb > On 19 December 2011 08:36, Antonio Petrelli > wrote: > > 2011/12/17 Mark Thomas > > > >> 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)
On 19 December 2011 08:36, Antonio Petrelli wrote: > 2011/12/17 Mark Thomas > >> 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.o
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: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/17 Mark Thomas > 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: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
2011/12/18 Mladen Turk > 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)
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: 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: 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)
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)
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: 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
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 > > 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
