RE: Build data in built artifacts
Since there are multiple jars, maybe it makes sense for each of the different modules to have a META-INF/openjpa-revision.properties file, and then have OpenJPAVersion print out the information for each of said resources in the classpath, if they're not the same. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Tuesday, August 22, 2006 7:46 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Build data in built artifacts I've gone ahead and committed something that does Bryan's suggestion: generates a /META-INF/revision.properties file and outputs the current Subversion revision number to it. The org.apache.openjpa.conf.OpenJPAVersion class will load that file and store it in the static REVISION_NUMBER field, as well as output it when the main() method of that class is run. It's not perfect, but it's better than not having the information at all. In the future, we might want to think about writing a Maven plugin that does this a little more smoothly. On Aug 22, 2006, at 2:11 PM, Bryan Noll wrote: I dorked with it some more, and got it to the point where it wrote out a properties file with the subversion revision info in it (a la David's example)... but then ran into a wall in terms of getting the scope of that property to hang around long enough to stuff it into. I hopped on the #maven irc at codehaus... and asked around... and it seems like it is simply not possible as of now. The only option I got was to manually create a MANIFEST.MF file that is under subversion control, then filter it so the correct value gets put in that way, but it seems cumbersome to me to have to manually maintain all those files. The next best thing would be to simply stuff a an openjpa- version.properties file in the jar that contains a line like: svn-revision=433722 Seems like a hack because its not actually going in the manifest where it would be ideal... but I guess the information is still there. I'm not sure I like either of those options... Marc Prud'hommeaux wrote: Bryan- FYI, I had played with this a little while ago ... I got the subversion revision number using the maven-antrun-plugin and xmlproperty task to parse the .svn/entries file, but I couldn't figure out how to pass the value of the property from the ant plugin to the global Maven properties so that it could be later embedded using the maven-jar-plugin. If you have any ideas on how to do this (maybe even by writing out a file from ant and reading it back in with Maven), that'd be great. This xmlproperty code that I wrote is actually still in the top- level pom.xml, it's just commented out. On Aug 14, 2006, at 2:14 PM, Bryan Noll wrote: Patrick... Looks like the OpenJPA version number is already getting tossed in there as: Implementation-Version: 0.9.0 We can stuff a subversion revision number in there by using 'maven-jar-plugin'... I just have to play with it a bit in order to get a latest and greatest rev number. Bryan Noll wrote: Lemme take a crack at it... Patrick Linskey wrote: Hi, I think it'd be nice if each of the modules could encode svn revision number and OpenJPA version number information into the built jars, presumably in a manifest entry. Does anyone have any knowledge about how to coerce this type of info into jars in a mvn environment? -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Build data in built artifacts
Interesting idea, although we'd need some way to figure our the names of the different resources or jars (possibly by the addition of a generic OpenJPAModule class or something that exists in each module). I would be hesitant to do it just so each jar could report the revision from a command-line utility, but if there are other possible uses for such a system that people can think of, it might be worth doing. On Aug 23, 2006, at 9:35 AM, Patrick Linskey wrote: Since there are multiple jars, maybe it makes sense for each of the different modules to have a META-INF/openjpa-revision.properties file, and then have OpenJPAVersion print out the information for each of said resources in the classpath, if they're not the same. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Tuesday, August 22, 2006 7:46 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Build data in built artifacts I've gone ahead and committed something that does Bryan's suggestion: generates a /META-INF/revision.properties file and outputs the current Subversion revision number to it. The org.apache.openjpa.conf.OpenJPAVersion class will load that file and store it in the static REVISION_NUMBER field, as well as output it when the main() method of that class is run. It's not perfect, but it's better than not having the information at all. In the future, we might want to think about writing a Maven plugin that does this a little more smoothly. On Aug 22, 2006, at 2:11 PM, Bryan Noll wrote: I dorked with it some more, and got it to the point where it wrote out a properties file with the subversion revision info in it (a la David's example)... but then ran into a wall in terms of getting the scope of that property to hang around long enough to stuff it into. I hopped on the #maven irc at codehaus... and asked around... and it seems like it is simply not possible as of now. The only option I got was to manually create a MANIFEST.MF file that is under subversion control, then filter it so the correct value gets put in that way, but it seems cumbersome to me to have to manually maintain all those files. The next best thing would be to simply stuff a an openjpa- version.properties file in the jar that contains a line like: svn-revision=433722 Seems like a hack because its not actually going in the manifest where it would be ideal... but I guess the information is still there. I'm not sure I like either of those options... Marc Prud'hommeaux wrote: Bryan- FYI, I had played with this a little while ago ... I got the subversion revision number using the maven-antrun-plugin and xmlproperty task to parse the .svn/entries file, but I couldn't figure out how to pass the value of the property from the ant plugin to the global Maven properties so that it could be later embedded using the maven-jar-plugin. If you have any ideas on how to do this (maybe even by writing out a file from ant and reading it back in with Maven), that'd be great. This xmlproperty code that I wrote is actually still in the top- level pom.xml, it's just commented out. On Aug 14, 2006, at 2:14 PM, Bryan Noll wrote: Patrick... Looks like the OpenJPA version number is already getting tossed in there as: Implementation-Version: 0.9.0 We can stuff a subversion revision number in there by using 'maven-jar-plugin'... I just have to play with it a bit in order to get a latest and greatest rev number. Bryan Noll wrote: Lemme take a crack at it... Patrick Linskey wrote: Hi, I think it'd be nice if each of the modules could encode svn revision number and OpenJPA version number information into the built jars, presumably in a manifest entry. Does anyone have any knowledge about how to coerce this type of info into jars in a mvn environment? -Patrick __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Build data in built artifacts
I guess I wasn't that clear. I was thinking that each jar would use the
same name (META-INF/openjpa-revision.properties), and then the
OpenJPAVersion code would do something like:
Enumeration urls = getClass().getClassLoader()
.getResources(META-INF/openjpa-revision.properties);
Map revisions = new HashMap();
String firstRevision = null;
boolean revisionsSame = true;
while (urls.hasMoreElements()) {
URL url = (URL) urls.nextElement();
String revision = getRevision(url);
revisions.put(url, revision);
if (firstRevision != null)
revisionsSame = firstRevision.equals(revision);
else
firstRevision = revision;
}
if (revisionsSame)
out.println(revision: + firstRevision);
else
out.println(revisions: + revisions);
I prefer using META-INF/openjpa-revision.properties to just
META-INF/revision.properties because someone else might have a resource
called META-INF/revision.properties in the classpath, but it seems
vanishingly unlikely that META-INF/openjpa-revision.properties is used
by others.
Thoughts?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of Marc Prud'hommeaux
Sent: Wednesday, August 23, 2006 9:43 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Build data in built artifacts
Interesting idea, although we'd need some way to figure our
the names
of the different resources or jars (possibly by the addition of a
generic OpenJPAModule class or something that exists in each
module).
I would be hesitant to do it just so each jar could report the
revision from a command-line utility, but if there are other
possible
uses for such a system that people can think of, it might be worth
doing.
On Aug 23, 2006, at 9:35 AM, Patrick Linskey wrote:
Since there are multiple jars, maybe it makes sense for each of the
different modules to have a
META-INF/openjpa-revision.properties file,
and then have OpenJPAVersion print out the information for each of
said
resources in the classpath, if they're not the same.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of Marc Prud'hommeaux
Sent: Tuesday, August 22, 2006 7:46 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Build data in built artifacts
I've gone ahead and committed something that does Bryan's
suggestion:
generates a /META-INF/revision.properties file and outputs the
current Subversion revision number to it.
The org.apache.openjpa.conf.OpenJPAVersion class will load
that file
and store it in the static REVISION_NUMBER field, as well
as output
it when the main() method of that class is run.
It's not perfect, but it's better than not having the
information at
all. In the future, we might want to think about writing a Maven
plugin that does this a little more smoothly.
On Aug 22, 2006, at 2:11 PM, Bryan Noll wrote:
I dorked with it some more, and got it to the point where it wrote
out a properties file with the subversion revision info in
it (a la
David's example)... but then ran into a wall in terms of getting
the scope of that property to hang around long enough to stuff it
into. I hopped on the #maven irc at codehaus... and asked
around... and it seems like it is simply not possible as of now.
The only option I got was to manually create a MANIFEST.MF file
that is under subversion control, then filter it so the correct
value gets put in that way, but it seems cumbersome to me to have
to manually maintain all those files.
The next best thing would be to simply stuff a an openjpa-
version.properties file in the jar that contains a line like:
svn-revision=433722
Seems like a hack because its not actually going in the manifest
where it would be ideal... but I guess the information is
still there.
I'm not sure I like either of those options...
Marc Prud'hommeaux wrote:
Bryan-
FYI, I had played with this a little while ago ... I got the
subversion revision number using the maven-antrun-plugin and
xmlproperty task to parse the .svn/entries file, but I couldn't
figure out how to pass the value of the property from the ant
plugin to the global Maven properties so that it could be later
embedded using the maven-jar-plugin. If you have any ideas on how
to do this (maybe even by writing out a file from ant and reading
it back in with Maven), that'd be great.
This xmlproperty code that I wrote is actually still in the top-
level pom.xml, it's just commented out.
On Aug 14, 2006, at 2:14 PM, Bryan Noll wrote:
Patrick...
Looks like the OpenJPA version number is already getting tossed
in there as:
Implementation-Version: 0.9.0
We can stuff a subversion revision number in there by using
'maven-jar-plugin'... I just have
Re: Build data in built artifacts
I dorked with it some more, and got it to the point where it wrote out a properties file with the subversion revision info in it (a la David's example)... but then ran into a wall in terms of getting the scope of that property to hang around long enough to stuff it into. I hopped on the #maven irc at codehaus... and asked around... and it seems like it is simply not possible as of now. The only option I got was to manually create a MANIFEST.MF file that is under subversion control, then filter it so the correct value gets put in that way, but it seems cumbersome to me to have to manually maintain all those files. The next best thing would be to simply stuff a an openjpa-version.properties file in the jar that contains a line like: svn-revision=433722 Seems like a hack because its not actually going in the manifest where it would be ideal... but I guess the information is still there. I'm not sure I like either of those options... Marc Prud'hommeaux wrote: Bryan- FYI, I had played with this a little while ago ... I got the subversion revision number using the maven-antrun-plugin and xmlproperty task to parse the .svn/entries file, but I couldn't figure out how to pass the value of the property from the ant plugin to the global Maven properties so that it could be later embedded using the maven-jar-plugin. If you have any ideas on how to do this (maybe even by writing out a file from ant and reading it back in with Maven), that'd be great. This xmlproperty code that I wrote is actually still in the top-level pom.xml, it's just commented out. On Aug 14, 2006, at 2:14 PM, Bryan Noll wrote: Patrick... Looks like the OpenJPA version number is already getting tossed in there as: Implementation-Version: 0.9.0 We can stuff a subversion revision number in there by using 'maven-jar-plugin'... I just have to play with it a bit in order to get a latest and greatest rev number. Bryan Noll wrote: Lemme take a crack at it... Patrick Linskey wrote: Hi, I think it'd be nice if each of the modules could encode svn revision number and OpenJPA version number information into the built jars, presumably in a manifest entry. Does anyone have any knowledge about how to coerce this type of info into jars in a mvn environment? -Patrick
Re: Build data in built artifacts
I've gone ahead and committed something that does Bryan's suggestion: generates a /META-INF/revision.properties file and outputs the current Subversion revision number to it. The org.apache.openjpa.conf.OpenJPAVersion class will load that file and store it in the static REVISION_NUMBER field, as well as output it when the main() method of that class is run. It's not perfect, but it's better than not having the information at all. In the future, we might want to think about writing a Maven plugin that does this a little more smoothly. On Aug 22, 2006, at 2:11 PM, Bryan Noll wrote: I dorked with it some more, and got it to the point where it wrote out a properties file with the subversion revision info in it (a la David's example)... but then ran into a wall in terms of getting the scope of that property to hang around long enough to stuff it into. I hopped on the #maven irc at codehaus... and asked around... and it seems like it is simply not possible as of now. The only option I got was to manually create a MANIFEST.MF file that is under subversion control, then filter it so the correct value gets put in that way, but it seems cumbersome to me to have to manually maintain all those files. The next best thing would be to simply stuff a an openjpa- version.properties file in the jar that contains a line like: svn-revision=433722 Seems like a hack because its not actually going in the manifest where it would be ideal... but I guess the information is still there. I'm not sure I like either of those options... Marc Prud'hommeaux wrote: Bryan- FYI, I had played with this a little while ago ... I got the subversion revision number using the maven-antrun-plugin and xmlproperty task to parse the .svn/entries file, but I couldn't figure out how to pass the value of the property from the ant plugin to the global Maven properties so that it could be later embedded using the maven-jar-plugin. If you have any ideas on how to do this (maybe even by writing out a file from ant and reading it back in with Maven), that'd be great. This xmlproperty code that I wrote is actually still in the top- level pom.xml, it's just commented out. On Aug 14, 2006, at 2:14 PM, Bryan Noll wrote: Patrick... Looks like the OpenJPA version number is already getting tossed in there as: Implementation-Version: 0.9.0 We can stuff a subversion revision number in there by using 'maven-jar-plugin'... I just have to play with it a bit in order to get a latest and greatest rev number. Bryan Noll wrote: Lemme take a crack at it... Patrick Linskey wrote: Hi, I think it'd be nice if each of the modules could encode svn revision number and OpenJPA version number information into the built jars, presumably in a manifest entry. Does anyone have any knowledge about how to coerce this type of info into jars in a mvn environment? -Patrick
Re: Build data in built artifacts
Here is the technique I use on OpenEJB. Note the version here is
hardcoded cause at the time ${pom.currentVersion} didn't work. They
may have fixed that since. Anyway, at runtime we just read this file
out of the classpath. Geronimo adopted the same technique.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phaseprocess-classes/phase
goals
goalrun/goal
/goals
configuration
tasks
tstamp/
replace file=target/classes/openejb-
version.properties
token=@VERSION-REPLACED-BY-MAVEN@
value=3.0-SNAPSHOT/
replace file=target/classes/openejb-
version.properties
token=@DATE-REPLACED-BY-MAVEN@
value=${DSTAMP}/
replace file=target/classes/openejb-
version.properties
token=@TIME-REPLACED-BY-MAVEN@
value=${TSTAMP}/
!-- Add *.properties files --
copy todir=target/classes
fileset dir=src/main/java
include name=**/*.properties/
/fileset
/copy
/tasks
/configuration
/execution
/executions
/plugin
On Aug 14, 2006, at 2:00 PM, Patrick Linskey wrote:
Hi,
I think it'd be nice if each of the modules could encode svn revision
number and OpenJPA version number information into the built jars,
presumably in a manifest entry. Does anyone have any knowledge
about how
to coerce this type of info into jars in a mvn environment?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
