You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2011/12/16 20:56:34 UTC
Publishing process for JARs for Maven Central
All,
There are currently two options for publishing JARs to Maven Central:
1. scp+rsync via people.a.o
2. Nexus
Personally, my only requirements are:
a) that the JARs reach Maven Central
b) publishing is as simple as running a single script
I don't particularly care about the details. As long as all I have to do
is run a script and the JARs end up in Maven Central I'm happy. I know
option 1 works and I assume 2 will work the same way. Therefore I have
no preference for either approach.
Does anyone else have any requirements / views that would suggest one
approach is better than the other?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Mladen Turk <mt...@apache.org>.
On 12/16/2011 08:56 PM, Mark Thomas wrote:
> All,
>
>
> I know option 1 works ...
>
> Does anyone else have any requirements / views that would suggest one
> approach is better than the other?
>
If it ain't broken don't fix it.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Phil Steitz <ph...@gmail.com>.
On Dec 17, 2011, at 6:44 AM, sebb <se...@gmail.com> wrote:
> On 17 December 2011 05:19, Phil Steitz <ph...@gmail.com> wrote:
>> On 12/16/11 12:56 PM, Mark Thomas wrote:
>>> All,
>>>
>>> There are currently two options for publishing JARs to Maven Central:
>>> 1. scp+rsync via people.a.o
>>> 2. Nexus
>>>
>>> Personally, my only requirements are:
>>> a) that the JARs reach Maven Central
>>> b) publishing is as simple as running a single script
>>
>> I would be very interested to know if anyone has figured out a way
>> to fully script Nexus. AFAIK, Nexus requires that you use the GUI
>
> I think that's the main advantage or Nexus - makes it difficult to
> accidentally release files.
> This happened at least once in Commons before we started using Nexus.
Only via the release plugin and not following the documented process at the time. Adding GUI steps and more mysterious software *decreases* control.
>
> AIUI there is a REST interface which could be scripted if one could
> find the docs.
> But I think it would negate one of the main benefits if this allowed
> releases to be published to Maven Central automatically.
Which the simple rsync setup that tomcat and some Commons holdouts still use does in a much simpler and more transparent way.
>
>> and also (sic) store credentials in a plaintext file. Maybe someone
>
> AFAIK that's not true - or at least if it is, that's due to using
> Maven deploy, rather than Nexus, which is not directly involved in the
> upload.
>
>> has figured out a way around this. I would be very interested to
>
> You can store the master password on a USB stick for Maven to use.
> Or you could use something like a TrueCrypt container file.
Thats what I meant above.
Phil
>
>> learn this so we can improve the not-quite-functional process that
>> we have been fumbling with in Commons [1]. FWIW, my NSHO is that if
>> you have a working script that produces good artifacts that can be
>> scpd to central, there is no reason to bring in proprietary
>> software, plaintext credential files or GUI steps.
>>
>> Phil
>> [1] http://wiki.apache.org/commons/UsingNexus
>>>
>>> I don't particularly care about the details. As long as all I have to do
>>> is run a script and the JARs end up in Maven Central I'm happy. I know
>>> option 1 works and I assume 2 will work the same way. Therefore I have
>>> no preference for either approach.
>>>
>>> Does anyone else have any requirements / views that would suggest one
>>> approach is better than the other?
>>>
>>> Mark
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by sebb <se...@gmail.com>.
On 17 December 2011 05:19, Phil Steitz <ph...@gmail.com> wrote:
> On 12/16/11 12:56 PM, Mark Thomas wrote:
>> All,
>>
>> There are currently two options for publishing JARs to Maven Central:
>> 1. scp+rsync via people.a.o
>> 2. Nexus
>>
>> Personally, my only requirements are:
>> a) that the JARs reach Maven Central
>> b) publishing is as simple as running a single script
>
> I would be very interested to know if anyone has figured out a way
> to fully script Nexus. AFAIK, Nexus requires that you use the GUI
I think that's the main advantage or Nexus - makes it difficult to
accidentally release files.
This happened at least once in Commons before we started using Nexus.
AIUI there is a REST interface which could be scripted if one could
find the docs.
But I think it would negate one of the main benefits if this allowed
releases to be published to Maven Central automatically.
> and also (sic) store credentials in a plaintext file. Maybe someone
AFAIK that's not true - or at least if it is, that's due to using
Maven deploy, rather than Nexus, which is not directly involved in the
upload.
> has figured out a way around this. I would be very interested to
You can store the master password on a USB stick for Maven to use.
Or you could use something like a TrueCrypt container file.
> learn this so we can improve the not-quite-functional process that
> we have been fumbling with in Commons [1]. FWIW, my NSHO is that if
> you have a working script that produces good artifacts that can be
> scpd to central, there is no reason to bring in proprietary
> software, plaintext credential files or GUI steps.
>
> Phil
> [1] http://wiki.apache.org/commons/UsingNexus
>>
>> I don't particularly care about the details. As long as all I have to do
>> is run a script and the JARs end up in Maven Central I'm happy. I know
>> option 1 works and I assume 2 will work the same way. Therefore I have
>> no preference for either approach.
>>
>> Does anyone else have any requirements / views that would suggest one
>> approach is better than the other?
>>
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Phil Steitz <ph...@gmail.com>.
On 12/16/11 12:56 PM, Mark Thomas wrote:
> All,
>
> There are currently two options for publishing JARs to Maven Central:
> 1. scp+rsync via people.a.o
> 2. Nexus
>
> Personally, my only requirements are:
> a) that the JARs reach Maven Central
> b) publishing is as simple as running a single script
I would be very interested to know if anyone has figured out a way
to fully script Nexus. AFAIK, Nexus requires that you use the GUI
and also (sic) store credentials in a plaintext file. Maybe someone
has figured out a way around this. I would be very interested to
learn this so we can improve the not-quite-functional process that
we have been fumbling with in Commons [1]. FWIW, my NSHO is that if
you have a working script that produces good artifacts that can be
scpd to central, there is no reason to bring in proprietary
software, plaintext credential files or GUI steps.
Phil
[1] http://wiki.apache.org/commons/UsingNexus
>
> I don't particularly care about the details. As long as all I have to do
> is run a script and the JARs end up in Maven Central I'm happy. I know
> option 1 works and I assume 2 will work the same way. Therefore I have
> no preference for either approach.
>
> Does anyone else have any requirements / views that would suggest one
> approach is better than the other?
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
On 17/12/2011 21:43, Konstantin Kolinko wrote:
> 2011/12/17 Antonio Petrelli <an...@gmail.com>:
>> If you release to a staging directory, the Maven metadata (containg info
>> about previous releases) are not there, so they are created from scratch.
>> So, after releasing in the staging directory and voting, the copy method
>> simply overwrite the old metadata with the new one (remember, *without the
>> old versions*).
>> So in the end, we needed to use the Maven stage plugin (deprecated), that:
>> * downloads the staged artifacts;
>> * reuploads them to the final destination.
>>
>
> Mark, the above issue mentioned by Antonio is what I think we already
> encountered with broken maven-metadata.xml. That is
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52124
>
> More detailed description is in
> https://issues.sonatype.org/browse/MVNCENTRAL-139
That was a broken Tomcat 6 build process. Tomcat 7 doesn't have that
problem (and now, neither does 6). Granted using Nexus would have
avoided that issue but it has taken 5 years (since the 6.0.0 tag) for
someone to complain. That suggests to me the issue is minor.
> Mark, when you do 7.0 releases, do you scp the maven-metadata.xml file?
I assume that the file gets correctly generated automatically.
> Do you have all previous releases of 7.0 in your local repository (so
> that the file is built correctly)?
No. I have 7.0.11 - 7.0.23 (mainly because I haven't cleaned it out in a
while). It looks like the build process grabs a copy of the metadata
from the remote repo, updates it to add the new version and then uploads
the updated file.
> If Nexus allows to prepare new releases without the need to keep old
> releases around, I am +1 for it.
As far as I can tell, Nexus and the scp+rsync process are the same in
this regard.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/12/17 Antonio Petrelli <an...@gmail.com>:
> If you release to a staging directory, the Maven metadata (containg info
> about previous releases) are not there, so they are created from scratch.
> So, after releasing in the staging directory and voting, the copy method
> simply overwrite the old metadata with the new one (remember, *without the
> old versions*).
> So in the end, we needed to use the Maven stage plugin (deprecated), that:
> * downloads the staged artifacts;
> * reuploads them to the final destination.
>
Mark, the above issue mentioned by Antonio is what I think we already
encountered with broken maven-metadata.xml. That is
https://issues.apache.org/bugzilla/show_bug.cgi?id=52124
More detailed description is in
https://issues.sonatype.org/browse/MVNCENTRAL-139
Mark, when you do 7.0 releases, do you scp the maven-metadata.xml file?
Do you have all previous releases of 7.0 in your local repository (so
that the file is built correctly)?
If Nexus allows to prepare new releases without the need to keep old
releases around, I am +1 for it.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
On 17/12/2011 19:10, Antonio Petrelli wrote:
> 2011/12/17 Mark Thomas <ma...@apache.org>
>> Personally, I am of the view "If it ain't broke, don't fix it". If there
>> was something we would gain by switching to Maven then I'd be interested
>> but given we have an established build process with Ant that a number of
>> committers are familiar with and that I'm not aware of any benefits of
>> moving to Maven then I don't see any compelling reason to switch.
>>
>
> Using Maven has several benefits (standardization of structure, lots of
> reusable plugins, supported by major IDEs),
Those are features, not benefits.
If you can demonstrate how switching to Maven will be better, then I am
all ears. So far Maven just looks different rather than better with the
disadvantage (for me at least) that Maven is unfamiliar whereas Ant is
familiar. There needs to be an incentive to go up the Maven learning
curve and I haven't seen one yet.
> I prefer speaking with facts and I love doing Maven reconstructions.
> Since Apache lets us use Git, though in a read-only way, and since I use
> and love Tomcat, I think that it's worth a try.
You are, of course, free to take a look at this. It might be more
productive to try and make the case for Maven before doing that work.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Antonio Petrelli <an...@gmail.com>.
2011/12/17 Mark Thomas <ma...@apache.org>
> On 17/12/2011 18:42, Antonio Petrelli wrote:
> > 2011/12/17 Mark Thomas <ma...@apache.org>
> >
> >> On 17/12/2011 18:35, Antonio Petrelli wrote:
> >>> 2011/12/17 Mark Thomas <ma...@apache.org>
> >>>
> >>>> On 17/12/2011 18:14, Antonio Petrelli wrote:
> >>>>> Ok then interprete my words as: now you can use a staging repository.
> >>>>> This way, artifacts may be tested *before* they are released.
> >>>>
> >>>> The scp+rsync process also has a staging repository (and using that
> did
> >>>> not cause any meta-data issues).
> >>>>
> >>>> The JARs are the standard Tomcat JARs. The Maven release process just
> >>>> adds the metadata files and moves the JARs + metadata around. Since
> the
> >>>> JARs are already tested as part of the Tomcat release process, we
> never
> >>>> had a need to use the staging repository and I don't see that
> changing.
> >>>>
> >>>> There is also a snapshot repository and we did use that early on in
> the
> >>>> Tomcat 7 development process (before the first release) mainly because
> >>>> one user who was doing a lot of testing was using Maven and the
> snapshot
> >>>> repository was the easiest way to get them the latest build. We
> stopped
> >>>> using the snapshot repository some time ago. I can't remember if it
> was
> >>>> after the first release or after the first stable release.
> >>>>
> >>>>
> >>>
> >>> Ok then using Nexus makes sense only if you are going to use Maven for
> >> all
> >>> the release process (it's a matter of two commands and a Nexus stage
> >>> promotion).
> >>> I think that now you should change the subject into: why should you
> >> switch
> >>> to pure Maven build process? :-D (Joking, but not too much)
> >>
> >> Yeah, that isn't going to happen :)
> >>
> >> I've seen way to much pain and grief with Maven on the Commons list to
> >> ever want to even think about converting the Tomcat build process to
> Maven.
> >>
> >
> > Commons? That's strange, they are only libraries. Probably they never had
> > <cringe-mode-off /> a Maven wizard like me <cringe-mode-on />.
> > Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try
> if
> > I can change this situation. I already did it for Velocity (using SVN).
> The
> > only difficulty is the website.
>
> Personally, I am of the view "If it ain't broke, don't fix it". If there
> was something we would gain by switching to Maven then I'd be interested
> but given we have an established build process with Ant that a number of
> committers are familiar with and that I'm not aware of any benefits of
> moving to Maven then I don't see any compelling reason to switch.
>
Using Maven has several benefits (standardization of structure, lots of
reusable plugins, supported by major IDEs), but, somehow, they still don't
convince hardcode Ant believers.
I prefer speaking with facts and I love doing Maven reconstructions.
Since Apache lets us use Git, though in a read-only way, and since I use
and love Tomcat, I think that it's worth a try.
Antonio
Re: Publishing process for JARs for Maven Central
Posted by Olivier Lamy <ol...@apache.org>.
Hello,
2011/12/18 jean-frederic clere <jf...@gmail.com>:
> On 12/17/2011 07:55 PM, Mark Thomas wrote:
>>
>> Personally, I am of the view "If it ain't broke, don't fix it". If there
>> was something we would gain by switching to Maven then I'd be interested
>> but given we have an established build process with Ant that a number of
>> committers are familiar with and that I'm not aware of any benefits of
>> moving to Maven then I don't see any compelling reason to switch.
>
>
> Using Maven would allow us to remove build.properties.default and download
> task that information would go in pom.xml. We can cut Tomcat in module more
> easily.
> The other thing is that Maven seems a more active project that Ant so we new
> feature easy and most IDE allow to import Maven project in IDE workspace.
>
> The problem of Maven is that we have to change the structure of our
> repository I think that the only problem.
I have started something here [1] which doesn't change the structure.
in tc7, just try mvn clean install -f maven/pom.xml (maven artifacts
will be installed)
BTW it's only a workaround to not change the structure and certainly
doesn't fix any issue with ide (and btw there are a lot things to fix
in this test)
I have started that but not continuing effort due to lack of interest.
It was really a start to produce maven artifacts needed by maven
plugin and was more easy to test with SNAPSHOTs build for me.
The question regarding changing build system is complicated: as you
tomcat core devs prefers ant why moving ?
At least for introducing more modularity, why rebuilding everything
every time ( what is the need to always rebuild jdbc pool module
whereas nothing has changed: this module could have an independent
release cycle as it's a library which can be used outside of tomcat
container).
As the embed api in 7 is pretty cool and available in maven
repositories, I'm sure more and more maven users will use it.
So using maven could be gain here, as hackers/users will probably want
to try provide patch (fixes or new feature) and without a maven build
they probably won't do it...
BTW if you decide to do/change something, as I have a bit of maven
knowledge, let me know if I can help.
>
> Cheers
>
> Jean-Frederic
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
[1] https://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/maven/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/17/2011 07:55 PM, Mark Thomas wrote:
> Personally, I am of the view "If it ain't broke, don't fix it". If there
> was something we would gain by switching to Maven then I'd be interested
> but given we have an established build process with Ant that a number of
> committers are familiar with and that I'm not aware of any benefits of
> moving to Maven then I don't see any compelling reason to switch.
Using Maven would allow us to remove build.properties.default and
download task that information would go in pom.xml. We can cut Tomcat in
module more easily.
The other thing is that Maven seems a more active project that Ant so we
new feature easy and most IDE allow to import Maven project in IDE
workspace.
The problem of Maven is that we have to change the structure of our
repository I think that the only problem.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
On 17/12/2011 18:42, Antonio Petrelli wrote:
> 2011/12/17 Mark Thomas <ma...@apache.org>
>
>> On 17/12/2011 18:35, Antonio Petrelli wrote:
>>> 2011/12/17 Mark Thomas <ma...@apache.org>
>>>
>>>> On 17/12/2011 18:14, Antonio Petrelli wrote:
>>>>> Ok then interprete my words as: now you can use a staging repository.
>>>>> This way, artifacts may be tested *before* they are released.
>>>>
>>>> The scp+rsync process also has a staging repository (and using that did
>>>> not cause any meta-data issues).
>>>>
>>>> The JARs are the standard Tomcat JARs. The Maven release process just
>>>> adds the metadata files and moves the JARs + metadata around. Since the
>>>> JARs are already tested as part of the Tomcat release process, we never
>>>> had a need to use the staging repository and I don't see that changing.
>>>>
>>>> There is also a snapshot repository and we did use that early on in the
>>>> Tomcat 7 development process (before the first release) mainly because
>>>> one user who was doing a lot of testing was using Maven and the snapshot
>>>> repository was the easiest way to get them the latest build. We stopped
>>>> using the snapshot repository some time ago. I can't remember if it was
>>>> after the first release or after the first stable release.
>>>>
>>>>
>>>
>>> Ok then using Nexus makes sense only if you are going to use Maven for
>> all
>>> the release process (it's a matter of two commands and a Nexus stage
>>> promotion).
>>> I think that now you should change the subject into: why should you
>> switch
>>> to pure Maven build process? :-D (Joking, but not too much)
>>
>> Yeah, that isn't going to happen :)
>>
>> I've seen way to much pain and grief with Maven on the Commons list to
>> ever want to even think about converting the Tomcat build process to Maven.
>>
>
> Commons? That's strange, they are only libraries. Probably they never had
> <cringe-mode-off /> a Maven wizard like me <cringe-mode-on />.
> Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if
> I can change this situation. I already did it for Velocity (using SVN). The
> only difficulty is the website.
Personally, I am of the view "If it ain't broke, don't fix it". If there
was something we would gain by switching to Maven then I'd be interested
but given we have an established build process with Ant that a number of
committers are familiar with and that I'm not aware of any benefits of
moving to Maven then I don't see any compelling reason to switch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
On 22/12/2011 09:17, jean-frederic clere wrote:
> On 12/21/2011 07:16 PM, Mark Thomas wrote:
>> There hasn't been any activity on this thread for a little while.
>>
>> I don't recall any significant arguments one way or the other for using
>> Nexus or scp+rsync.
>>
>> Since Jean-Frederic has switched all the Maven artifact release scripts
>> to use Nexus, I intend to do the following:
>>
>> - See what happens when I try and do the next Tomcat 7 release using
>> Nexus
>> - Fix anything that doesn't work
>
> Don't hesitate to ping me on that.
Don't worry, I won't ;)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/21/2011 07:16 PM, Mark Thomas wrote:
> There hasn't been any activity on this thread for a little while.
>
> I don't recall any significant arguments one way or the other for using
> Nexus or scp+rsync.
>
> Since Jean-Frederic has switched all the Maven artifact release scripts
> to use Nexus, I intend to do the following:
>
> - See what happens when I try and do the next Tomcat 7 release using Nexus
> - Fix anything that doesn't work
Don't hesitate to ping me on that.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
There hasn't been any activity on this thread for a little while.
I don't recall any significant arguments one way or the other for using
Nexus or scp+rsync.
Since Jean-Frederic has switched all the Maven artifact release scripts
to use Nexus, I intend to do the following:
- See what happens when I try and do the next Tomcat 7 release using Nexus
- Fix anything that doesn't work
- Review the ease of use of scp+rsync and Nexus and if there are issues,
complexities etc with Nexus switch back to scp+rsync otherwise stick
with Nexus
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by sebb <se...@gmail.com>.
On 18 December 2011 18:03, Phil Steitz <ph...@gmail.com> wrote:
> On 12/17/11 11:42 AM, Antonio Petrelli wrote:
>> 2011/12/17 Mark Thomas <ma...@apache.org>
>>
>>> On 17/12/2011 18:35, Antonio Petrelli wrote:
>>>> 2011/12/17 Mark Thomas <ma...@apache.org>
>>>>
>>>>> On 17/12/2011 18:14, Antonio Petrelli wrote:
>>>>>> Ok then interprete my words as: now you can use a staging repository.
>>>>>> This way, artifacts may be tested *before* they are released.
>>>>> The scp+rsync process also has a staging repository (and using that did
>>>>> not cause any meta-data issues).
>>>>>
>>>>> The JARs are the standard Tomcat JARs. The Maven release process just
>>>>> adds the metadata files and moves the JARs + metadata around. Since the
>>>>> JARs are already tested as part of the Tomcat release process, we never
>>>>> had a need to use the staging repository and I don't see that changing.
>>>>>
>>>>> There is also a snapshot repository and we did use that early on in the
>>>>> Tomcat 7 development process (before the first release) mainly because
>>>>> one user who was doing a lot of testing was using Maven and the snapshot
>>>>> repository was the easiest way to get them the latest build. We stopped
>>>>> using the snapshot repository some time ago. I can't remember if it was
>>>>> after the first release or after the first stable release.
>>>>>
>>>>>
>>>> Ok then using Nexus makes sense only if you are going to use Maven for
>>> all
>>>> the release process (it's a matter of two commands and a Nexus stage
>>>> promotion).
>>>> I think that now you should change the subject into: why should you
>>> switch
>>>> to pure Maven build process? :-D (Joking, but not too much)
>>> Yeah, that isn't going to happen :)
>>>
>>> I've seen way to much pain and grief with Maven on the Commons list to
>>> ever want to even think about converting the Tomcat build process to Maven.
>>>
>> Commons? That's strange, they are only libraries. Probably they never had
>> <cringe-mode-off /> a Maven wizard like me <cringe-mode-on />.
>
> We have several maven committers on the PMC and have been using
> maven since the 1.x days.
>
> One thing we have learned is that maven builds require regular care
> and feeding. We are on version 23 of the Commons Parent pom. One
That's partly due to Maven, but quite a few of those changes are due
to new requirements, and updated plugins etc.
Having a shared parent pom means more attention has to be paid to it
and less to the component poms.
So I don't think that's an entirely fair statistic.
But I do agree that fixing Maven issues is generally a lot harder than
fixing Ant issues.
> statistic that I have often thought would be interesting to look at
> is how much time (maybe proxied by number of metadata commits) is
> spent maintaining maven vs Ant builds. I wonder if on net maven
> saves time? The tomcat Ant build has been relatively stable
> compared to the maven projects I know. Could be I am wrong, but I
> bet tomcat has overall spent less time fussing with its build than
> the average ASF maven project. In Commons, our success getting to
> periods of stability (we are between stable points now) has depended
> on having multiple deeply maven-knowledgeable people prepared to do
> the work to keep component builds up to date with maven,
> ASF/Sonatype infrastructure and plugin changes. If there are several
> tomcat committers willing to step up to do this, then I am sure you
> can get it to work. Otherwise, you are likely better off staying
> with Ant.
I'm inclined to agree here.
I think Commons is somewhat different as it has many small components
independently released.
Maven enforces some conventions which mean the build processes tend to
be similar across projects.
Ant is more flexible and it would take a fair amount of work to ensure
that all Commons components used standardised Ant build targets.
Also Common components are libraries that are often consumed by other
Maven projects.
Tomcat is mainly a stand-alone download.
I don't particularly like Maven - there's far too much built-in magic,
which is not always properly explained - but it does have benefits in
standardisation and (some aspects of its) dependency management.
> Phil
>> Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if
>> I can change this situation. I already did it for Velocity (using SVN). The
>> only difficulty is the website.
>>
>> Antonio
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Phil Steitz <ph...@gmail.com>.
On 12/17/11 11:42 AM, Antonio Petrelli wrote:
> 2011/12/17 Mark Thomas <ma...@apache.org>
>
>> On 17/12/2011 18:35, Antonio Petrelli wrote:
>>> 2011/12/17 Mark Thomas <ma...@apache.org>
>>>
>>>> On 17/12/2011 18:14, Antonio Petrelli wrote:
>>>>> Ok then interprete my words as: now you can use a staging repository.
>>>>> This way, artifacts may be tested *before* they are released.
>>>> The scp+rsync process also has a staging repository (and using that did
>>>> not cause any meta-data issues).
>>>>
>>>> The JARs are the standard Tomcat JARs. The Maven release process just
>>>> adds the metadata files and moves the JARs + metadata around. Since the
>>>> JARs are already tested as part of the Tomcat release process, we never
>>>> had a need to use the staging repository and I don't see that changing.
>>>>
>>>> There is also a snapshot repository and we did use that early on in the
>>>> Tomcat 7 development process (before the first release) mainly because
>>>> one user who was doing a lot of testing was using Maven and the snapshot
>>>> repository was the easiest way to get them the latest build. We stopped
>>>> using the snapshot repository some time ago. I can't remember if it was
>>>> after the first release or after the first stable release.
>>>>
>>>>
>>> Ok then using Nexus makes sense only if you are going to use Maven for
>> all
>>> the release process (it's a matter of two commands and a Nexus stage
>>> promotion).
>>> I think that now you should change the subject into: why should you
>> switch
>>> to pure Maven build process? :-D (Joking, but not too much)
>> Yeah, that isn't going to happen :)
>>
>> I've seen way to much pain and grief with Maven on the Commons list to
>> ever want to even think about converting the Tomcat build process to Maven.
>>
> Commons? That's strange, they are only libraries. Probably they never had
> <cringe-mode-off /> a Maven wizard like me <cringe-mode-on />.
We have several maven committers on the PMC and have been using
maven since the 1.x days.
One thing we have learned is that maven builds require regular care
and feeding. We are on version 23 of the Commons Parent pom. One
statistic that I have often thought would be interesting to look at
is how much time (maybe proxied by number of metadata commits) is
spent maintaining maven vs Ant builds. I wonder if on net maven
saves time? The tomcat Ant build has been relatively stable
compared to the maven projects I know. Could be I am wrong, but I
bet tomcat has overall spent less time fussing with its build than
the average ASF maven project. In Commons, our success getting to
periods of stability (we are between stable points now) has depended
on having multiple deeply maven-knowledgeable people prepared to do
the work to keep component builds up to date with maven,
ASF/Sonatype infrastructure and plugin changes. If there are several
tomcat committers willing to step up to do this, then I am sure you
can get it to work. Otherwise, you are likely better off staying
with Ant.
Phil
> Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if
> I can change this situation. I already did it for Velocity (using SVN). The
> only difficulty is the website.
>
> Antonio
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Antonio Petrelli <an...@gmail.com>.
2011/12/17 Mark Thomas <ma...@apache.org>
> On 17/12/2011 18:35, Antonio Petrelli wrote:
> > 2011/12/17 Mark Thomas <ma...@apache.org>
> >
> >> On 17/12/2011 18:14, Antonio Petrelli wrote:
> >>> Ok then interprete my words as: now you can use a staging repository.
> >>> This way, artifacts may be tested *before* they are released.
> >>
> >> The scp+rsync process also has a staging repository (and using that did
> >> not cause any meta-data issues).
> >>
> >> The JARs are the standard Tomcat JARs. The Maven release process just
> >> adds the metadata files and moves the JARs + metadata around. Since the
> >> JARs are already tested as part of the Tomcat release process, we never
> >> had a need to use the staging repository and I don't see that changing.
> >>
> >> There is also a snapshot repository and we did use that early on in the
> >> Tomcat 7 development process (before the first release) mainly because
> >> one user who was doing a lot of testing was using Maven and the snapshot
> >> repository was the easiest way to get them the latest build. We stopped
> >> using the snapshot repository some time ago. I can't remember if it was
> >> after the first release or after the first stable release.
> >>
> >>
> >
> > Ok then using Nexus makes sense only if you are going to use Maven for
> all
> > the release process (it's a matter of two commands and a Nexus stage
> > promotion).
> > I think that now you should change the subject into: why should you
> switch
> > to pure Maven build process? :-D (Joking, but not too much)
>
> Yeah, that isn't going to happen :)
>
> I've seen way to much pain and grief with Maven on the Commons list to
> ever want to even think about converting the Tomcat build process to Maven.
>
Commons? That's strange, they are only libraries. Probably they never had
<cringe-mode-off /> a Maven wizard like me <cringe-mode-on />.
Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if
I can change this situation. I already did it for Velocity (using SVN). The
only difficulty is the website.
Antonio
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
On 17/12/2011 18:35, Antonio Petrelli wrote:
> 2011/12/17 Mark Thomas <ma...@apache.org>
>
>> On 17/12/2011 18:14, Antonio Petrelli wrote:
>>> Ok then interprete my words as: now you can use a staging repository.
>>> This way, artifacts may be tested *before* they are released.
>>
>> The scp+rsync process also has a staging repository (and using that did
>> not cause any meta-data issues).
>>
>> The JARs are the standard Tomcat JARs. The Maven release process just
>> adds the metadata files and moves the JARs + metadata around. Since the
>> JARs are already tested as part of the Tomcat release process, we never
>> had a need to use the staging repository and I don't see that changing.
>>
>> There is also a snapshot repository and we did use that early on in the
>> Tomcat 7 development process (before the first release) mainly because
>> one user who was doing a lot of testing was using Maven and the snapshot
>> repository was the easiest way to get them the latest build. We stopped
>> using the snapshot repository some time ago. I can't remember if it was
>> after the first release or after the first stable release.
>>
>>
>
> Ok then using Nexus makes sense only if you are going to use Maven for all
> the release process (it's a matter of two commands and a Nexus stage
> promotion).
> I think that now you should change the subject into: why should you switch
> to pure Maven build process? :-D (Joking, but not too much)
Yeah, that isn't going to happen :)
I've seen way to much pain and grief with Maven on the Commons list to
ever want to even think about converting the Tomcat build process to Maven.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Antonio Petrelli <an...@gmail.com>.
2011/12/17 Mark Thomas <ma...@apache.org>
> On 17/12/2011 18:14, Antonio Petrelli wrote:
> > Ok then interprete my words as: now you can use a staging repository.
> > This way, artifacts may be tested *before* they are released.
>
> The scp+rsync process also has a staging repository (and using that did
> not cause any meta-data issues).
>
> The JARs are the standard Tomcat JARs. The Maven release process just
> adds the metadata files and moves the JARs + metadata around. Since the
> JARs are already tested as part of the Tomcat release process, we never
> had a need to use the staging repository and I don't see that changing.
>
> There is also a snapshot repository and we did use that early on in the
> Tomcat 7 development process (before the first release) mainly because
> one user who was doing a lot of testing was using Maven and the snapshot
> repository was the easiest way to get them the latest build. We stopped
> using the snapshot repository some time ago. I can't remember if it was
> after the first release or after the first stable release.
>
>
Ok then using Nexus makes sense only if you are going to use Maven for all
the release process (it's a matter of two commands and a Nexus stage
promotion).
I think that now you should change the subject into: why should you switch
to pure Maven build process? :-D (Joking, but not too much)
Antonio
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
On 17/12/2011 18:14, Antonio Petrelli wrote:
> Ok then interprete my words as: now you can use a staging repository.
> This way, artifacts may be tested *before* they are released.
The scp+rsync process also has a staging repository (and using that did
not cause any meta-data issues).
The JARs are the standard Tomcat JARs. The Maven release process just
adds the metadata files and moves the JARs + metadata around. Since the
JARs are already tested as part of the Tomcat release process, we never
had a need to use the staging repository and I don't see that changing.
There is also a snapshot repository and we did use that early on in the
Tomcat 7 development process (before the first release) mainly because
one user who was doing a lot of testing was using Maven and the snapshot
repository was the easiest way to get them the latest build. We stopped
using the snapshot repository some time ago. I can't remember if it was
after the first release or after the first stable release.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Antonio Petrelli <an...@gmail.com>.
2011/12/17 Mark Thomas <ma...@apache.org>
> On 17/12/2011 18:08, Antonio Petrelli wrote:
> > 2011/12/16 Mark Thomas <ma...@apache.org>
> >
> >> There are currently two options for publishing JARs to Maven Central:
> >> 1. scp+rsync via people.a.o
> >> 2. Nexus
> >>
> >
> > In my experience in Tiles releases, the only problem we had with scp +
> > simple copy (we did not use rsync) is that this process breaks Maven
> > metadata.
> > I try to explain myself.
> > If you release to a staging directory, the Maven metadata (containg info
> > about previous releases) are not there, so they are created from scratch.
> > So, after releasing in the staging directory and voting, the copy method
> > simply overwrite the old metadata with the new one (remember, *without
> the
> > old versions*).
> > So in the end, we needed to use the Maven stage plugin (deprecated),
> that:
> > * downloads the staged artifacts;
> > * reuploads them to the final destination.
>
> That is not an issue.
>
> Tomcat doesn't release to a staging repo first. The Maven artefact
> release is only done after the release vote has passed. If you look at
> the Tomcat 7 metadata you'll see that all versions are present.
>
> > Inside Nexus, you simply "promote" the staged repository, without the
> > problem of downloading and uploading again.
>
> That is not a problem with the scp+rsync process used by the Tomcat
> project.
>
Ok then interprete my words as: now you can use a staging repository.
This way, artifacts may be tested *before* they are released.
Antonio
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
On 17/12/2011 18:08, Antonio Petrelli wrote:
> 2011/12/16 Mark Thomas <ma...@apache.org>
>
>> There are currently two options for publishing JARs to Maven Central:
>> 1. scp+rsync via people.a.o
>> 2. Nexus
>>
>
> In my experience in Tiles releases, the only problem we had with scp +
> simple copy (we did not use rsync) is that this process breaks Maven
> metadata.
> I try to explain myself.
> If you release to a staging directory, the Maven metadata (containg info
> about previous releases) are not there, so they are created from scratch.
> So, after releasing in the staging directory and voting, the copy method
> simply overwrite the old metadata with the new one (remember, *without the
> old versions*).
> So in the end, we needed to use the Maven stage plugin (deprecated), that:
> * downloads the staged artifacts;
> * reuploads them to the final destination.
That is not an issue.
Tomcat doesn't release to a staging repo first. The Maven artefact
release is only done after the release vote has passed. If you look at
the Tomcat 7 metadata you'll see that all versions are present.
> Inside Nexus, you simply "promote" the staged repository, without the
> problem of downloading and uploading again.
That is not a problem with the scp+rsync process used by the Tomcat project.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Antonio Petrelli <an...@gmail.com>.
2011/12/16 Mark Thomas <ma...@apache.org>
> There are currently two options for publishing JARs to Maven Central:
> 1. scp+rsync via people.a.o
> 2. Nexus
>
In my experience in Tiles releases, the only problem we had with scp +
simple copy (we did not use rsync) is that this process breaks Maven
metadata.
I try to explain myself.
If you release to a staging directory, the Maven metadata (containg info
about previous releases) are not there, so they are created from scratch.
So, after releasing in the staging directory and voting, the copy method
simply overwrite the old metadata with the new one (remember, *without the
old versions*).
So in the end, we needed to use the Maven stage plugin (deprecated), that:
* downloads the staged artifacts;
* reuploads them to the final destination.
Inside Nexus, you simply "promote" the staged repository, without the
problem of downloading and uploading again.
Antonio
Re: Publishing process for JARs for Maven Central
Posted by sebb <se...@gmail.com>.
On 16 December 2011 23:45, Yoav Shapira <yo...@apache.org> wrote:
> On Fri, Dec 16, 2011 at 2:56 PM, Mark Thomas <ma...@apache.org> wrote:
>> All,
>>
>> There are currently two options for publishing JARs to Maven Central:
>> 1. scp+rsync via people.a.o
>> 2. Nexus
>
> I don't have a strong preference between them. Is there a difference
> between the two approaches in how fast the JARs are available for
> download?
AFAIK it's the same.
AIUI the artifacts are still deployed to the same distribution area.
Nexus copies them across when the RM releases the staging repo, rather
than the RM doing the copy directly.
BTW, Nexus takes care of maintaining the Maven metadata.
It also checks that the signature is valid and uses a public key (I
think this is done on Close)
I think it also creates hashes if required.
See http://www.apache.org/dev/publishing-maven-artifacts.html and
linked docs for some more info on Nexus.
> Yoav
>
>>
>> Personally, my only requirements are:
>> a) that the JARs reach Maven Central
>> b) publishing is as simple as running a single script
>>
>> I don't particularly care about the details. As long as all I have to do
>> is run a script and the JARs end up in Maven Central I'm happy. I know
>> option 1 works and I assume 2 will work the same way. Therefore I have
>> no preference for either approach.
>>
>> Does anyone else have any requirements / views that would suggest one
>> approach is better than the other?
>>
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Yoav Shapira <yo...@apache.org>.
On Fri, Dec 16, 2011 at 2:56 PM, Mark Thomas <ma...@apache.org> wrote:
> All,
>
> There are currently two options for publishing JARs to Maven Central:
> 1. scp+rsync via people.a.o
> 2. Nexus
I don't have a strong preference between them. Is there a difference
between the two approaches in how fast the JARs are available for
download?
Yoav
>
> Personally, my only requirements are:
> a) that the JARs reach Maven Central
> b) publishing is as simple as running a single script
>
> I don't particularly care about the details. As long as all I have to do
> is run a script and the JARs end up in Maven Central I'm happy. I know
> option 1 works and I assume 2 will work the same way. Therefore I have
> no preference for either approach.
>
> Does anyone else have any requirements / views that would suggest one
> approach is better than the other?
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/17/2011 07:27 PM, Mark Thomas wrote:
> Jean-Frederic, what was your motivation for moving Tomcat to Nexus?
1 - The good thing in Nexus is that we can check the result of our
"deploy-release" and drop is we screw it (multi upload can fail and we
don't know when the mirroring stars).
2 - Users using maven can test easy the jar in staging Nexus repository.
3 - I was looking to fix BZ 52124 a clean way.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
Posted by Mark Thomas <ma...@apache.org>.
On 16/12/2011 19:56, Mark Thomas wrote:
> All,
>
> There are currently two options for publishing JARs to Maven Central:
> 1. scp+rsync via people.a.o
> 2. Nexus
>
> Personally, my only requirements are:
> a) that the JARs reach Maven Central
> b) publishing is as simple as running a single script
>
> I don't particularly care about the details. As long as all I have to do
> is run a script and the JARs end up in Maven Central I'm happy. I know
> option 1 works and I assume 2 will work the same way. Therefore I have
> no preference for either approach.
>
> Does anyone else have any requirements / views that would suggest one
> approach is better than the other?
More info from [1].
1 means running a single script (after the release vote has passed)
2 means running a single script (before or after the release vote) and
then a couple of clicks in Nexus to promote the JARs once the release
vote passes.
Nexus pros: The Maven artefacts can be available sooner since we can
upload them while the release vote is running.
Nexus cons: What was a single step to release the Maven JARs is now
multiple steps.
I think I am still neutral on this.
Jean-Frederic, what was your motivation for moving Tomcat to Nexus?
Mark
[1] https://issues.apache.org/jira/browse/INFRA-4162
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org