You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Daniel Mueller <da...@gmail.com> on 2007/06/09 16:03:40 UTC
publishing sources to the maven-repo
Hi folks,
It would be nice if you'd publish the source jars to the maven-repo as well.
This enables IDEs which evaluate the dependencies in a pom to download the
sources for dependencies and you can quickly help fixing bugs or simply
study the code at leisure.
To achieve this you can use the maven-source-plugin[1]. You have basically
three ways to go about it:
- If you generate the distribution by hand you can simply add an
additional target when building as described in the maven guide to
repository uploading[2] (as detailed in step 2 of the guide, eg. 'mvn clean
source:jar javadoc:jar deploy' (I haven't used repository:bundle-create
before and it seems it can only be invoked on leaf projects)).
- If you want to incorporate it into your pom you can copy the
<profile> section of the first example in [3]. You'd then have to build your
sources with either -P release-profile (see [4] for more) or
-DperformRelease at the end of your build command.
- If you want to be able to do it handsfree, then you can simply add
the <plugins> section to the project/build element (but this adds time to
every build, which is at least for the javadoc unnecessary).
If you have an automated build it doesn't matter too much which one you use.
The proposed change makes the build.xml at least partially obsolete. But I
take it you still need it to put together the source distribution for the
apache.org download site and also because the development is easier without
an IDE [5]?
I have only checked httpcomponents-core, but I assume this applies to the
other httpcomponent projects as well. If you change a pom I propose to
change the org.apache.httpcomponents:project pom, because then every
subcomponent inherits the changes. The changes to the build process should
be also for every project.
This post is pretty extensive, but I saw on the mailinglist that at least
Roland didn't like Maven too much a year ago [5]. I don't know if this has
changed, or if I can help with any outstanding issues. I don't consider
myself to be authorative on maven, but I switched recently all projects at
our workplace from ant builds to maven. The projects were large'ish and
included a big hierarchical project with ~50 subcomponents, each built by
its own ant build script. In the end we had practically built our own maven
with ant, which was the point to reconsider. The transition went without
major problems beside the usual 'Doh, how am I gonna solve this one'... I'm
not saying maven solved everything nicely but in the end it was a net-gain.
Thanks and keep up the good work
Dan
[1] http://maven.apache.org/plugins/maven-source-plugin/
[2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
[3] http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
[4]
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
[5]
http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg04234.html
Re: publishing sources to the maven-repo
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2007-06-10 at 12:33 +0200, Daniel Mueller wrote:
> Hi Oleg,
>
> Which one of the stated variants could be implemented? I have not the
> slightest clue about how you actually do releases, so it's a bit difficult
> to help.
Hi Daniel,
I still need to document the release process in more details [1] which I
intend to do in the course of the coming ALPHA5 release.
Currently I build release assemblies in a semi-manual fashion. I usually
deploy the release artifacts to the Maven repository first, then I run
javadoc and clover reports and finally build the release assemblies to
be made available for download.
I leave the decision as to which approach to take up to you. See what
makes more sense. I guess the simpler the better. I also do not expect
it to be fully hands-free. I think it is reasonable to expect some
degree of intelligence from the release manager, so some manual
interactions during the release process are fine by me.
Cheers,
Oleg
[1] https://issues.apache.org/jira/browse/HTTPCORE-62
> Are they done by hand and then provided to the maven team? Or are
> they somehow done automatically. I think at least for the continuous
> integration stuff (built by gump, I asume) you'd have to change the invoked
> command.
>
> Cheers,
> Daniel
>
> On 6/9/07, Oleg Kalnichevski <ol...@apache.org> wrote:
> >
> > Hi Daniel,
> >
> > We are basically using Ant scripts for those development tasks where
> > speed really matters (compile / run test cycle) and Maven2 for more
> > complex tasks such as cutting and deploying releases. Two build systems
> > can coexist in parallel as long as both are maintained.
> >
> > > I have only checked httpcomponents-core, but I assume this applies to
> > the
> > > other httpcomponent projects as well. If you change a pom I propose to
> > > change the org.apache.httpcomponents:project pom, because then every
> > > subcomponent inherits the changes. The changes to the build process
> > should
> > > be also for every project.
> > >
> > > This post is pretty extensive, but I saw on the mailinglist that at
> > least
> > > Roland didn't like Maven too much a year ago [5]. I don't know if this
> > has
> > > changed, or if I can help with any outstanding issues. I don't consider
> > > myself to be authorative on maven, but I switched recently all projects
> > at
> > > our workplace from ant builds to maven. The projects were large'ish and
> > > included a big hierarchical project with ~50 subcomponents, each built
> > by
> > > its own ant build script. In the end we had practically built our own
> > maven
> > > with ant, which was the point to reconsider. The transition went without
> > > major problems beside the usual 'Doh, how am I gonna solve this one'...
> > I'm
> > > not saying maven solved everything nicely but in the end it was a
> > net-gain.
> > >
> >
> > I was a long time Maven skeptic and only recently started warming up to
> > it. To me Maven really shines at reducing costs of splitting complex
> > libraries into multiple single purpose modules, which in its turn helps
> > reduce the number of requisite external dependencies for the upstream
> > users. It was also my experience that maintaining a large number of
> > sub-modules using Ant tended to be significantly more laborious and
> > error-prone.
> >
> > So, please do feel free to go ahead and submit patches for proposed
> > changes. I hope Roland will not veto it.
> >
> > Cheers
> >
> > Oleg
> >
> >
> > >
> > > Thanks and keep up the good work
> > > Dan
> > >
> > > [1] http://maven.apache.org/plugins/maven-source-plugin/
> > > [2]
> > http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> > > [3]
> > http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
> > > [4]
> > >
> > http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> > > [5]
> > >
> > http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg04234.html
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > httpcomponents-dev-help@jakarta.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: publishing sources to the maven-repo
Posted by Daniel Mueller <da...@digitalstrider.com>.
Hi Oleg,
Which one of the stated variants could be implemented? I have not the
slightest clue about how you actually do releases, so it's a bit difficult
to help. Are they done by hand and then provided to the maven team? Or are
they somehow done automatically. I think at least for the continuous
integration stuff (built by gump, I asume) you'd have to change the invoked
command.
Cheers,
Daniel
On 6/9/07, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> Hi Daniel,
>
> We are basically using Ant scripts for those development tasks where
> speed really matters (compile / run test cycle) and Maven2 for more
> complex tasks such as cutting and deploying releases. Two build systems
> can coexist in parallel as long as both are maintained.
>
> > I have only checked httpcomponents-core, but I assume this applies to
> the
> > other httpcomponent projects as well. If you change a pom I propose to
> > change the org.apache.httpcomponents:project pom, because then every
> > subcomponent inherits the changes. The changes to the build process
> should
> > be also for every project.
> >
> > This post is pretty extensive, but I saw on the mailinglist that at
> least
> > Roland didn't like Maven too much a year ago [5]. I don't know if this
> has
> > changed, or if I can help with any outstanding issues. I don't consider
> > myself to be authorative on maven, but I switched recently all projects
> at
> > our workplace from ant builds to maven. The projects were large'ish and
> > included a big hierarchical project with ~50 subcomponents, each built
> by
> > its own ant build script. In the end we had practically built our own
> maven
> > with ant, which was the point to reconsider. The transition went without
> > major problems beside the usual 'Doh, how am I gonna solve this one'...
> I'm
> > not saying maven solved everything nicely but in the end it was a
> net-gain.
> >
>
> I was a long time Maven skeptic and only recently started warming up to
> it. To me Maven really shines at reducing costs of splitting complex
> libraries into multiple single purpose modules, which in its turn helps
> reduce the number of requisite external dependencies for the upstream
> users. It was also my experience that maintaining a large number of
> sub-modules using Ant tended to be significantly more laborious and
> error-prone.
>
> So, please do feel free to go ahead and submit patches for proposed
> changes. I hope Roland will not veto it.
>
> Cheers
>
> Oleg
>
>
> >
> > Thanks and keep up the good work
> > Dan
> >
> > [1] http://maven.apache.org/plugins/maven-source-plugin/
> > [2]
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> > [3]
> http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
> > [4]
> >
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> > [5]
> >
> http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg04234.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>
Re: publishing sources to the maven-repo
Posted by Roland Weber <os...@dubioso.net>.
Hi Oleg, Daniel,
> So, please do feel free to go ahead and submit patches for proposed
> changes. I hope Roland will not veto it.
No problem. Since I'm not using the Ant build in SVN anymore,
I'm not aware of anyone using it at all. It's not like anyone
noticed that module-niossl never had a build.xml in the first
place, right? From a maintainance point of view, deleting the
Ant build would be the most simple solution.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: publishing sources to the maven-repo
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2007-06-09 at 16:03 +0200, Daniel Mueller wrote:
> Hi folks,
>
> It would be nice if you'd publish the source jars to the maven-repo as well.
> This enables IDEs which evaluate the dependencies in a pom to download the
> sources for dependencies and you can quickly help fixing bugs or simply
> study the code at leisure.
>
> To achieve this you can use the maven-source-plugin[1]. You have basically
> three ways to go about it:
>
> - If you generate the distribution by hand you can simply add an
> additional target when building as described in the maven guide to
> repository uploading[2] (as detailed in step 2 of the guide, eg. 'mvn clean
> source:jar javadoc:jar deploy' (I haven't used repository:bundle-create
> before and it seems it can only be invoked on leaf projects)).
> - If you want to incorporate it into your pom you can copy the
> <profile> section of the first example in [3]. You'd then have to build your
> sources with either -P release-profile (see [4] for more) or
> -DperformRelease at the end of your build command.
> - If you want to be able to do it handsfree, then you can simply add
> the <plugins> section to the project/build element (but this adds time to
> every build, which is at least for the javadoc unnecessary).
>
> If you have an automated build it doesn't matter too much which one you use.
>
> The proposed change makes the build.xml at least partially obsolete. But I
> take it you still need it to put together the source distribution for the
> apache.org download site and also because the development is easier without
> an IDE [5]?
>
Hi Daniel,
We are basically using Ant scripts for those development tasks where
speed really matters (compile / run test cycle) and Maven2 for more
complex tasks such as cutting and deploying releases. Two build systems
can coexist in parallel as long as both are maintained.
> I have only checked httpcomponents-core, but I assume this applies to the
> other httpcomponent projects as well. If you change a pom I propose to
> change the org.apache.httpcomponents:project pom, because then every
> subcomponent inherits the changes. The changes to the build process should
> be also for every project.
>
> This post is pretty extensive, but I saw on the mailinglist that at least
> Roland didn't like Maven too much a year ago [5]. I don't know if this has
> changed, or if I can help with any outstanding issues. I don't consider
> myself to be authorative on maven, but I switched recently all projects at
> our workplace from ant builds to maven. The projects were large'ish and
> included a big hierarchical project with ~50 subcomponents, each built by
> its own ant build script. In the end we had practically built our own maven
> with ant, which was the point to reconsider. The transition went without
> major problems beside the usual 'Doh, how am I gonna solve this one'... I'm
> not saying maven solved everything nicely but in the end it was a net-gain.
>
I was a long time Maven skeptic and only recently started warming up to
it. To me Maven really shines at reducing costs of splitting complex
libraries into multiple single purpose modules, which in its turn helps
reduce the number of requisite external dependencies for the upstream
users. It was also my experience that maintaining a large number of
sub-modules using Ant tended to be significantly more laborious and
error-prone.
So, please do feel free to go ahead and submit patches for proposed
changes. I hope Roland will not veto it.
Cheers
Oleg
>
> Thanks and keep up the good work
> Dan
>
> [1] http://maven.apache.org/plugins/maven-source-plugin/
> [2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> [3] http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
> [4]
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> [5]
> http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg04234.html
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas
Posted by Roland Weber <os...@dubioso.net>.
Hi Daniel,
> One of the simple options to solve the problem is to use a profile. its
> very
> likely that custom built distributions are built with:
> mvn package or mvn install
> and not
> mvn package -P release-profile
> and you could still issue a warning in the pom as xml comment, to not do
> that and giving the reasons. In the profile configuration can be whatever
> change to the build procedure you'd like (version file, ant-style filtering
> of classes or ressources, whatever). While it's not fail proof I think it
> would solve the problem nicely and without requiring too much thinking
> during the build process (which I definitely like: "did you do A before you
> did B and shipped the thing to be dropped on production servers"
> immediately
> followed by a wail of despair ;)
>
> Would that solve the problem or is a more secure solution necessary?
I like that approach. The concept has similarities with a local
properties file, and is more general as it allows even actions
to be modified. I'll keep that in mind when I think about the
versioning problem in the future.
thanks,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas (was: Re: publishing sources to the maven-repo)
Posted by Daniel Mueller <da...@digitalstrider.com>.
> The goal of version detection is to log in debug output which
> versions of the various modules are in the environment. The
> basic approach would be to package a version.properties file
> with each module (in different packages), then hard-code a list
> of modules in a version-detection class.
>
> My trickiest requirement for version detection is the following:
> if somebody downloads one of our source builds and re-builds it
> locally instead of using the release JAR, that has to show up
> in the version log. The most likely reason for a local build are
> changes to out classes, and we should be aware of that fact when
> asked to give support.
> To achieve that with Ant, I would use a <copy> task with filters
> on the properties files. I think Maven has a step prepare-source
> in which to do such things. I would hard-code a version number
> SNAPSHOT in the build.xml and override that from the command line
> or in a local build.properties when doing a release build.
> If someone did a local build bypassing Ant, the properties would
> either be missing, or they would show the unreplaced filter tags.
> A local build using Ant would show version SNAPSHOT.
>
> I don't doubt that Maven can copy and filter properties files as
> well as Ant can. But if Maven gets the version from the pom.xml,
> which is shipped set to the release version, that wouldn't be
> enough.
> One option is to keep not only the version, but also a build
> timestamp in the properties files. Then we could see from the
> timestamps which modules are release JARs and which aren't.
>
One of the simple options to solve the problem is to use a profile. its very
likely that custom built distributions are built with:
mvn package or mvn install
and not
mvn package -P release-profile
and you could still issue a warning in the pom as xml comment, to not do
that and giving the reasons. In the profile configuration can be whatever
change to the build procedure you'd like (version file, ant-style filtering
of classes or ressources, whatever). While it's not fail proof I think it
would solve the problem nicely and without requiring too much thinking
during the build process (which I definitely like: "did you do A before you
did B and shipped the thing to be dropped on production servers" immediately
followed by a wail of despair ;)
Would that solve the problem or is a more secure solution necessary?
Cheers,
Daniel
PS: you can also activate the profile with a system property. see here[1]
for more details.
[1]
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
Re: version detection ideas
Posted by Daniel Mueller <da...@digitalstrider.com>.
I'm pretty sure that the md5 approach is infeasible. the problem is that you
change the md5 hash of the jar as soon as you pack the md5 hash of the jar
into the jar, which is kinda recursive. You could let the people do a
hashing over their jar to see if they got the genuine version, but that a
bit much to ask from user of your library (I would be a bit set off when I
requested help and the first thing asked of me was the md5 hash of all the
jars used from this particular project).
I think what you want to have is simply a textfile per jar with version
information which contains among others buildtime, checkouttime/version,
cvs/svn tag/branch name if it was a release, maybe more. You could even
provide a Util which gathers together all those version file, and prints
them on the console, which can then easily be used to the list-members what
they are looking at.
just my 2 cents
Cheers,
Daniel
On 6/10/07, sebb <se...@gmail.com> wrote:
>
> On 10/06/07, Roland Weber <os...@dubioso.net> wrote:
> > Hi Sebastian,
> >
> > >> basic approach would be to package a version.properties file
> > >> with each module (in different packages), then hard-code a list
> > >> of modules in a version-detection class.
> > >
> > > An alternative might be to use the svn revision - there would then be
> > > just one number to worry about.
> >
> > The version detection must tell us that someone is using
> > httpnio.jar from release alpha5 with httpcore.jar from alpha4
> > and httpclient.jar alpha1. We need one number per module/jar.
>
> OK, I see. But you could use the current revision in each jar in the
> build.
>
> > The advantage of using "$Revision: 54395$" instead of "alpha1"
> > is that we don't need a build step to bring it into a property
> > file. But it doesn't address my trickiest requirement. If we
> > drop that requirement, revision numbers are a good option. If
> > we do have a build step, I'd prefer the more readable version.
> >
> > > Would it not just be simpler to ask for the MD5 of the jar(s) if you
> > > suspect that a local version has been created?
> >
> > That requires us to have a suspicion in the first place, which
> > may take several round trips to build. Then we'd have to tell
> > people how to generate MD5s (minor problem if md5sum is installed,
> > but is it on a Windows box?). Last but not least, it assumes that
> > people know which JARs are actually picked up from the classpath(s).
> > But you are right, the trickiest requirement will be a rather
> > rare case. If all other requirements can be satisfied with a
> > simpler solution, this is an option to address the tricky one.
>
> Since they must have Java, one could provide a Java md5 utility...
>
> > > Indeed, why not generate the MD5s and log them in the debug output?
> >
> > Access the JAR file from somewhere in the classpath to generate
> > an MD5 sum at runtime? I don't think that's an option, and in
> > particular not for a class that's supposed to go into HttpCore.
> > File access and a cryptographic hash sum just for debug output?
>
> Not sure I understand the objection...
> It would only need to be done once per jar, and only if debug was enabled.
>
> > >> If someone did a local build bypassing Ant, the properties would
> > >> either be missing, or they would show the unreplaced filter tags.
> > >> A local build using Ant would show version SNAPSHOT.
> > >
> > > What's to stop them using the release identifier?
> >
> > I'm not tryig to prevent anyone from deliberately stealing our
> > time. It's meant for folks that forget to tell us that they've
> > made local modifications, or think that their modifications are
> > not related to the problem, or that don't even know about the
> > modifications because somebody else gave them the JARs they
> > should use.
>
> OK, understood; that simplifies matters.
>
> > >> One option is to keep not only the version, but also a build
> > >> timestamp in the properties files. Then we could see from the
> > >> timestamps which modules are release JARs and which aren't.
> > >
> > > Yes, that would be safer.
> > >
> > > But MD5 hashes would work just as well?
> >
> > For MD5 hashing at runtime, see above. Putting an MD5 hash
> > into a property file within each JAR requires postprocessing
> > of the JARs. Oleg will like this idea no more than I do.
>
> Agreed there's no point adding the MD5 to existing jars.
> [Indeed adding a property file to the jar will change the MD5 of the jar.]
>
> I was referring to the MD5 ideas mentioned above.
>
> > I'll reconsider whether the trickiest requirement is really
> > important enough to merit an extra step in the build. If not,
> > I will give the $Revision$ option careful consideration.
>
> You need a file that is updated for every release that you make.
> [Which is one reason why I used svnant for nightly builds]
>
> > thanks and cheers,
> > Roland
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>
Re: version detection ideas
Posted by Roland Weber <os...@dubioso.net>.
Hello Sebastian,
>> Access the JAR file from somewhere in the classpath to generate
>> an MD5 sum at runtime? I don't think that's an option, and in
>> particular not for a class that's supposed to go into HttpCore.
>> File access and a cryptographic hash sum just for debug output?
>
> Not sure I understand the objection...
> It would only need to be done once per jar, and only if debug was enabled.
Problem 1: how do I get the JAR file from the classloader?
Assuming there is a JAR _file_ in the first place, and not
some other kind of archive that's accessed in a non-file
way, such as an HTTP classloader or an .ear/.war archive.
Even if we had a method to get entries for a PATH variable
from a classloader, how'd we know which of the entries is
the library in question? The JAR file could be renamed, or
classes from several JARs might be joined into one.
Problem 2: we even try to avoid System.getProperties in
HttpCore, since that operation is subject to permissions
checked by a security manager. There is no file access
required for the functionality HttpCore provides, why
should we require that permission for debug output? And
in an embedded environment we may not even have a file
system. Nor a provider for cryptographic hash sums.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas
Posted by sebb <se...@gmail.com>.
On 10/06/07, Roland Weber <os...@dubioso.net> wrote:
> Hi Sebastian,
>
> >> basic approach would be to package a version.properties file
> >> with each module (in different packages), then hard-code a list
> >> of modules in a version-detection class.
> >
> > An alternative might be to use the svn revision - there would then be
> > just one number to worry about.
>
> The version detection must tell us that someone is using
> httpnio.jar from release alpha5 with httpcore.jar from alpha4
> and httpclient.jar alpha1. We need one number per module/jar.
OK, I see. But you could use the current revision in each jar in the build.
> The advantage of using "$Revision: 54395$" instead of "alpha1"
> is that we don't need a build step to bring it into a property
> file. But it doesn't address my trickiest requirement. If we
> drop that requirement, revision numbers are a good option. If
> we do have a build step, I'd prefer the more readable version.
>
> > Would it not just be simpler to ask for the MD5 of the jar(s) if you
> > suspect that a local version has been created?
>
> That requires us to have a suspicion in the first place, which
> may take several round trips to build. Then we'd have to tell
> people how to generate MD5s (minor problem if md5sum is installed,
> but is it on a Windows box?). Last but not least, it assumes that
> people know which JARs are actually picked up from the classpath(s).
> But you are right, the trickiest requirement will be a rather
> rare case. If all other requirements can be satisfied with a
> simpler solution, this is an option to address the tricky one.
Since they must have Java, one could provide a Java md5 utility...
> > Indeed, why not generate the MD5s and log them in the debug output?
>
> Access the JAR file from somewhere in the classpath to generate
> an MD5 sum at runtime? I don't think that's an option, and in
> particular not for a class that's supposed to go into HttpCore.
> File access and a cryptographic hash sum just for debug output?
Not sure I understand the objection...
It would only need to be done once per jar, and only if debug was enabled.
> >> If someone did a local build bypassing Ant, the properties would
> >> either be missing, or they would show the unreplaced filter tags.
> >> A local build using Ant would show version SNAPSHOT.
> >
> > What's to stop them using the release identifier?
>
> I'm not tryig to prevent anyone from deliberately stealing our
> time. It's meant for folks that forget to tell us that they've
> made local modifications, or think that their modifications are
> not related to the problem, or that don't even know about the
> modifications because somebody else gave them the JARs they
> should use.
OK, understood; that simplifies matters.
> >> One option is to keep not only the version, but also a build
> >> timestamp in the properties files. Then we could see from the
> >> timestamps which modules are release JARs and which aren't.
> >
> > Yes, that would be safer.
> >
> > But MD5 hashes would work just as well?
>
> For MD5 hashing at runtime, see above. Putting an MD5 hash
> into a property file within each JAR requires postprocessing
> of the JARs. Oleg will like this idea no more than I do.
Agreed there's no point adding the MD5 to existing jars.
[Indeed adding a property file to the jar will change the MD5 of the jar.]
I was referring to the MD5 ideas mentioned above.
> I'll reconsider whether the trickiest requirement is really
> important enough to merit an extra step in the build. If not,
> I will give the $Revision$ option careful consideration.
You need a file that is updated for every release that you make.
[Which is one reason why I used svnant for nightly builds]
> thanks and cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas
Posted by sebb <se...@gmail.com>.
On 23/06/07, Roland Weber <os...@dubioso.net> wrote:
> sebb wrote:
> >
> > Or you can use the svnant Ant task to get most SVN properties.
>
> Alas, our releases are built by Maven.
Which can use Ant code; see for example the MD5 generation in:
http://svn.apache.org/viewvc/jakarta/commons/proper/modeler/trunk/maven.xml?view=markup
However, I'm not sure if Maven can use external Ant tasks ...
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas
Posted by Roland Weber <os...@dubioso.net>.
sebb wrote:
>
> Or you can use the svnant Ant task to get most SVN properties.
Alas, our releases are built by Maven.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas
Posted by sebb <se...@gmail.com>.
On 23/06/07, Roland Weber <os...@dubioso.net> wrote:
> Roland Weber wrote:
> >
> > The advantage of using "$Revision: 54395$" instead of "alpha1"
> > is that we don't need a build step to bring it into a property
> > file.
>
> Wrong. $Revision$ will provide the revision in which the
> particular file was last changed, not the global revision.
> We'll need external processing of the properties files to
> bring in the global revision number. But then we can also
> bring in the release version.
>
> http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html
>
Or you can use the svnant Ant task to get most SVN properties.
S
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas
Posted by Roland Weber <os...@dubioso.net>.
Roland Weber wrote:
>
> The advantage of using "$Revision: 54395$" instead of "alpha1"
> is that we don't need a build step to bring it into a property
> file.
Wrong. $Revision$ will provide the revision in which the
particular file was last changed, not the global revision.
We'll need external processing of the properties files to
bring in the global revision number. But then we can also
bring in the release version.
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas
Posted by Roland Weber <os...@dubioso.net>.
Hi Sebastian,
>> basic approach would be to package a version.properties file
>> with each module (in different packages), then hard-code a list
>> of modules in a version-detection class.
>
> An alternative might be to use the svn revision - there would then be
> just one number to worry about.
The version detection must tell us that someone is using
httpnio.jar from release alpha5 with httpcore.jar from alpha4
and httpclient.jar alpha1. We need one number per module/jar.
The advantage of using "$Revision: 54395$" instead of "alpha1"
is that we don't need a build step to bring it into a property
file. But it doesn't address my trickiest requirement. If we
drop that requirement, revision numbers are a good option. If
we do have a build step, I'd prefer the more readable version.
> Would it not just be simpler to ask for the MD5 of the jar(s) if you
> suspect that a local version has been created?
That requires us to have a suspicion in the first place, which
may take several round trips to build. Then we'd have to tell
people how to generate MD5s (minor problem if md5sum is installed,
but is it on a Windows box?). Last but not least, it assumes that
people know which JARs are actually picked up from the classpath(s).
But you are right, the trickiest requirement will be a rather
rare case. If all other requirements can be satisfied with a
simpler solution, this is an option to address the tricky one.
> Indeed, why not generate the MD5s and log them in the debug output?
Access the JAR file from somewhere in the classpath to generate
an MD5 sum at runtime? I don't think that's an option, and in
particular not for a class that's supposed to go into HttpCore.
File access and a cryptographic hash sum just for debug output?
>> If someone did a local build bypassing Ant, the properties would
>> either be missing, or they would show the unreplaced filter tags.
>> A local build using Ant would show version SNAPSHOT.
>
> What's to stop them using the release identifier?
I'm not tryig to prevent anyone from deliberately stealing our
time. It's meant for folks that forget to tell us that they've
made local modifications, or think that their modifications are
not related to the problem, or that don't even know about the
modifications because somebody else gave them the JARs they
should use.
>> One option is to keep not only the version, but also a build
>> timestamp in the properties files. Then we could see from the
>> timestamps which modules are release JARs and which aren't.
>
> Yes, that would be safer.
>
> But MD5 hashes would work just as well?
For MD5 hashing at runtime, see above. Putting an MD5 hash
into a property file within each JAR requires postprocessing
of the JARs. Oleg will like this idea no more than I do.
I'll reconsider whether the trickiest requirement is really
important enough to merit an extra step in the build. If not,
I will give the $Revision$ option careful consideration.
thanks and cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: version detection ideas (was: Re: publishing sources to the maven-repo)
Posted by sebb <se...@gmail.com>.
On 10/06/07, Roland Weber <os...@dubioso.net> wrote:
> Hi Daniel,
>
> >> update
> >> properties files with the version number during release builds,
> >
> > If you could elaborate a bit more on your idea, I'm gonna think about it. I
> > solved a similar problem at work and probably can find a solution faster.
>
> The goal of version detection is to log in debug output which
> versions of the various modules are in the environment. The
> basic approach would be to package a version.properties file
> with each module (in different packages), then hard-code a list
> of modules in a version-detection class.
An alternative might be to use the svn revision - there would then be
just one number to worry about.
I'm doing this for the nightly JMeter builds.
[See nightly target in build.xml for the details]
> My trickiest requirement for version detection is the following:
> if somebody downloads one of our source builds and re-builds it
> locally instead of using the release JAR, that has to show up
> in the version log. The most likely reason for a local build are
> changes to out classes, and we should be aware of that fact when
> asked to give support.
Would it not just be simpler to ask for the MD5 of the jar(s) if you
suspect that a local version has been created?
Indeed, why not generate the MD5s and log them in the debug output?
> To achieve that with Ant, I would use a <copy> task with filters
> on the properties files. I think Maven has a step prepare-source
> in which to do such things. I would hard-code a version number
> SNAPSHOT in the build.xml and override that from the command line
> or in a local build.properties when doing a release build.
> If someone did a local build bypassing Ant, the properties would
> either be missing, or they would show the unreplaced filter tags.
> A local build using Ant would show version SNAPSHOT.
What's to stop them using the release identifier?
> I don't doubt that Maven can copy and filter properties files as
> well as Ant can. But if Maven gets the version from the pom.xml,
> which is shipped set to the release version, that wouldn't be
> enough.
> One option is to keep not only the version, but also a build
> timestamp in the properties files. Then we could see from the
> timestamps which modules are release JARs and which aren't.
Yes, that would be safer.
But MD5 hashes would work just as well?
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
version detection ideas (was: Re: publishing sources to the maven-repo)
Posted by Roland Weber <os...@dubioso.net>.
Hi Daniel,
>> update
>> properties files with the version number during release builds,
>
> If you could elaborate a bit more on your idea, I'm gonna think about it. I
> solved a similar problem at work and probably can find a solution faster.
The goal of version detection is to log in debug output which
versions of the various modules are in the environment. The
basic approach would be to package a version.properties file
with each module (in different packages), then hard-code a list
of modules in a version-detection class.
My trickiest requirement for version detection is the following:
if somebody downloads one of our source builds and re-builds it
locally instead of using the release JAR, that has to show up
in the version log. The most likely reason for a local build are
changes to out classes, and we should be aware of that fact when
asked to give support.
To achieve that with Ant, I would use a <copy> task with filters
on the properties files. I think Maven has a step prepare-source
in which to do such things. I would hard-code a version number
SNAPSHOT in the build.xml and override that from the command line
or in a local build.properties when doing a release build.
If someone did a local build bypassing Ant, the properties would
either be missing, or they would show the unreplaced filter tags.
A local build using Ant would show version SNAPSHOT.
I don't doubt that Maven can copy and filter properties files as
well as Ant can. But if Maven gets the version from the pom.xml,
which is shipped set to the release version, that wouldn't be
enough.
One option is to keep not only the version, but also a build
timestamp in the properties files. Then we could see from the
timestamps which modules are release JARs and which aren't.
> The simple truth is that I'm very
>> unlikely to ever learn Maven well enough to come to like it :-)
>
> I spoke the same words some time ago ;)
My two current job responsibilities are one non-coding project,
and one where a demo is coded using an Eclipse-based tool and
nobody but me cares about a decent build process at all. I sure
won't learn Maven in-depth on private time ;)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: publishing sources to the maven-repo
Posted by Daniel Mueller <da...@digitalstrider.com>.
Hi Roland,
To me, Maven is a release build tool. But I don't build releases,
> Oleg takes care of that.
Fair enough.
If I wanted to keep up with everything going on in this project,
> I would have had to spend time on learning at least Maven, NIO,
> and Spring. I prefer to spend what little time I have available
> on coding. I had an idea last year (as recently as December) to
> code some kind of version detection for debug reporting. But I
> had to drop that idea because it would have required to update
> properties files with the version number during release builds,
> and I don't want to spend several week-ends on learning Maven
> just to support a few hours of coding. Actually, I'm not even
> sure whether my idea could be implemented with Maven, as it
> seems (from my remote point of view) that version identifiers
> are hard-coded in POM files rather than being passed in when
> invoking the release build.
If you could elaborate a bit more on your idea, I'm gonna think about it. I
solved a similar problem at work and probably can find a solution faster.
The simple truth is that I'm very
> unlikely to ever learn Maven well enough to come to like it :-)
I spoke the same words some time ago ;)
If you can help Oleg and others with the release process,
> your helping hand is appreciated by me as well.
I'm gonna have a look what I can do when I encounter problems. So far, the
things work pretty well and I haven't found major hurdles, but if you'd like
some additional things, please state them somewhere (feature request in jira
maybe).
Cheers
Daniel
Re: publishing sources to the maven-repo
Posted by Roland Weber <os...@dubioso.net>.
Hi Daniel,
> I saw on the mailinglist that at least
> Roland didn't like Maven too much a year ago [5].
To me, Maven is a release build tool. But I don't build releases,
Oleg takes care of that. For development work, you need something
like Ant that provides more fine-grained building. I'm using Ant
explicitly, others use it under the covers of Eclipse.
If I wanted to keep up with everything going on in this project,
I would have had to spend time on learning at least Maven, NIO,
and Spring. I prefer to spend what little time I have available
on coding. I had an idea last year (as recently as December) to
code some kind of version detection for debug reporting. But I
had to drop that idea because it would have required to update
properties files with the version number during release builds,
and I don't want to spend several week-ends on learning Maven
just to support a few hours of coding. Actually, I'm not even
sure whether my idea could be implemented with Maven, as it
seems (from my remote point of view) that version identifiers
are hard-coded in POM files rather than being passed in when
invoking the release build. The simple truth is that I'm very
unlikely to ever learn Maven well enough to come to like it :-)
If you can help Oleg and others with the release process,
your helping hand is appreciated by me as well.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org