Re: Update version to SNAPSHOT
Hi David, I guess this would be the place. There's no content yet. So I added a pointer to the DistributionStrategy page but it didn't quite work. I'm used to the other wiki and all you do there is type a page name and the wiki creates a link to it. So I need to get used to Confluence! Thanks, Craig On Aug 16, 2006, at 2:03 PM, David Blevins wrote: Speaking of wikis, I created a Confluence space in cwiki at Geir's request some time ago. (http://cwiki.apache.org/confluence/display/ openjpa/Index) Is that something you guys want to use? -David On Aug 15, 2006, at 8:08 PM, Craig L Russell wrote: This discussion would be great to capture on the wiki for the time (not too far away) when we will actually package and ship some code. Craig On Aug 15, 2006, at 7:20 PM, David Blevins wrote: On Aug 15, 2006, at 7:42 AM, Craig L Russell wrote: On Aug 15, 2006, at 6:38 AM, Patrick Linskey wrote: Check out the Assembly plugin and it's predefined jar-with-dependencies descriptor[1]. I'm pretty sure that most people using Maven will just have a runtime dependency on the core OpenJPA library and be done with it, but it's always nice for Ant users. Exactly -- mvn users will use the dependencies, but people who want to download and use the distribution directly may not want a billion little jars. Yes, my experience says it's ok to have 10 dependencies on e.g. commons-logger, antlr, etc. but having 10 dependencies on openjpa-kernel4, openjpa-kernel5, openjpa-api, openjpa-blah is annoying. So if possible, I'd also like to have a jar with all the stuff in it. That'd be nice. Some jar that contains all the openjpa-*.jar files is perfect for my needs. The good news is that the maven- assembly-plugin allows you to define several assembly xml files and build multiple archives containing whatever you like. So if people want, we could have: openjpa-0.9.0-full.jar // contains all openjpa code, openjpa- *.jars merged openjpa-0.9.0-nodep.jar // contains all openjpa code and all third party dependency jars There's a naming convention for this kind of thing, hope I've got it right. -David Craig -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. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Update version to SNAPSHOT
On Aug 14, 2006, at 8:52 PM, Craig L Russell wrote: Hi Marc, On Aug 14, 2006, at 6:53 PM, Marc Prud'hommeaux wrote: Patrick- What's the difference between SNAPSHOT and -dev, in mavenese? I wasn't suggesting that what we talked about was better; just tossing some more fuel on the fire. I don't know how well documented it is, but my understanding is that the -SNAPSHOT suffix (which, I believe, is automatically appended if some snapshot=true attribute is set in the pom.xml) is treated specially: when resolving dependencies, rather than re- using the cached jars for any SNAPSHOT-suffix'd jars, Maven will re-download it every time (or, at least, check to make sure the cached version is the most recent one). This is handy for nightlies and things like that, since you don't want to have to up the version every single time, but you do want people who are developing against snapshots to always have the latest version. At least that's my understanding. Agrees with mine. So if you have a xxx-0.9.0-dev, maven considers that to be a fixed release and won't automatically update it (ever). If you want to refresh it, you manually delete your cached version and when maven can't find it, maven will download new bits. Or you mvn install xxx and if xxx has to be rebuilt, the install goal replaces the bits in your local repository. If you have a 0.9.0-SNAPSHOT, maven will always try to download the latest copy on every invocation of maven. If you prefer that maven not do this, run maven with the -o option and it won't try to download new versions of SNAPSHOT. Usually, SNAPSHOT builds are not published, so maven never finds the SNAPSHOT build in your remote repositories. That's about right with the note that maven2 is a bit different. By default it will only check for SNAPSHOTs once a day unless you: - use one of the update now flags, like -U - change the default the updatePolicy (options are: never, always, daily, or interval:NN) Changing the default is done on a per repo basis like this: repository idapache-snapshots-m1/id nameApache Maven 1 Snapshots Repository/name urlhttp://people.apache.org/repo/m1-snapshot- repository/url layoutlegacy/layout snapshots enabledtrue/enabled updatePolicydaily/updatePolicy checksumPolicyignore/checksumPolicy /snapshots releases enabledtrue/enabled /releases /repository It might be good to run through the common dev scenarios in detail to see which model would work best for this project, since there are so many sub-projects. Craig, you're making me jealous I lost count of the poms in Geronimo after 100. Course I shouldn't complain in front of the Maven guys, I think they have more pom files than all of Apache put together :) -David Craig On Aug 14, 2006, at 6:43 PM, Patrick Linskey wrote: I spoke to Geir about this a bunch last week; he suggested we use a number-dev nomenclature, so that it'd be clear that the current build is a dev build rather than a well-known numbered release. So, this would mean we'd have 0.9.0-dev, meaning that there are differences since the 0.9.0 release itself. Ok, well I don't want to cause problems if it's a done deal. Just a couple FYIs, maven will still treat that as a final version -- once downloaded, it won't check for newer versions. Also, maven will consider 0.9.0 to be greater than 0.9.0-dev. What's the difference between SNAPSHOT and -dev, in mavenese? I wasn't suggesting that what we talked about was better; just tossing some more fuel on the fire. Also, does anyone know what's involved in making snapshots happen on a regular basis (say, nightly iff an svn change happened that day)? With a couple patches to your root pom I can hook you up to Apache's Continuum install on vmbuild.apache.org (very slow but works). Publishing jars from there is still a bit tricky, but we might be able to figure something out. We've got a TeamCity server up and running at BEA (working on getting one in the DMZ...); it publishes artifacts. So, we could probably do something to get it to rsync the built artifacts somewhere or something like that. -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. Craig Russell Architect, Sun Java Enterprise System
Re: Update version to SNAPSHOT
On Aug 14, 2006, at 10:11 PM, Brett Porter wrote: On 15/08/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: On Mon, 2006-08-14 at 20:57 -0700, Patrick Linskey wrote: Does anyone know of existing mvn technology to merge resource files? To easily assemble jars together? Check out the Assembly plugin and it's predefined jar-with-dependencies descriptor[1]. I'm pretty sure that most people using Maven will just have a runtime dependency on the core OpenJPA library and be done with it, but it's always nice for Ant users. [1]: http://maven.apache.org/plugins/maven-assembly-plugin/predefined.html Note that that will not merge anything you need in the META-INF directory. It does do it for plexus components.xml files though, so maybe it's a good time to make that pluggable. It'll definitely add the files from all the META-INF directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? -David
Re: Update version to SNAPSHOT
On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote: Note that that will not merge anything you need in the META-INF directory. It does do it for plexus components.xml files though, so maybe it's a good time to make that pluggable. It'll definitely add the files from all the META-INF directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. -David
Re: Update version to SNAPSHOT
On Aug 15, 2006, at 11:06 AM, David Blevins wrote: On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote: Note that that will not merge anything you need in the META-INF directory. It does do it for plexus components.xml files though, so maybe it's a good time to make that pluggable. It'll definitely add the files from all the META-INF directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. So would it be easier to write a merge-manifest method or to restrict manifest services with the same name to one of the build modules? Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Update version to SNAPSHOT
On Aug 15, 2006, at 11:40 AM, Craig L Russell wrote: On Aug 15, 2006, at 11:06 AM, David Blevins wrote: On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote: Note that that will not merge anything you need in the META-INF directory. It does do it for plexus components.xml files though, so maybe it's a good time to make that pluggable. It'll definitely add the files from all the META-INF directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. So would it be easier to write a merge-manifest method or to restrict manifest services with the same name to one of the build modules? Sorry, I think I'm making things clear as mud :) I get the feeling we don't even have the issue Brett was mentioning. Aside from the MANIFEST.MF file itself, are there any jars of our own that contain the same file in the same place in the jar and those contents are different and need to be merged together? It's pretty easy to make a new MANIFEST.MF that better describes the new uber jar. -David
Re: Update version to SNAPSHOT
David- are there any jars of our own that contain the same file in the same place in the jar and those contents are different and need to be merged together? The only cases I know of are some of the files in services/. E.g.: openjpa-jdbc/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation openjpa-persistence-jdbc/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation openjpa-persistence/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation It's probably not rocket science to fix these (we would would just need to figure out a way to append them to each other), but it would prevent OpenJPA from working if we were to just merge the jars and overwrite same-named files. On Aug 15, 2006, at 12:46 PM, David Blevins wrote: On Aug 15, 2006, at 11:40 AM, Craig L Russell wrote: On Aug 15, 2006, at 11:06 AM, David Blevins wrote: On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote: Note that that will not merge anything you need in the META-INF directory. It does do it for plexus components.xml files though, so maybe it's a good time to make that pluggable. It'll definitely add the files from all the META-INF directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. So would it be easier to write a merge-manifest method or to restrict manifest services with the same name to one of the build modules? Sorry, I think I'm making things clear as mud :) I get the feeling we don't even have the issue Brett was mentioning. Aside from the MANIFEST.MF file itself, are there any jars of our own that contain the same file in the same place in the jar and those contents are different and need to be merged together? It's pretty easy to make a new MANIFEST.MF that better describes the new uber jar. -David
Re: Update version to SNAPSHOT
On Aug 15, 2006, at 12:56 PM, Marc Prud'hommeaux wrote: David- are there any jars of our own that contain the same file in the same place in the jar and those contents are different and need to be merged together? The only cases I know of are some of the files in services/. E.g.: openjpa-jdbc/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation openjpa-persistence-jdbc/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation openjpa-persistence/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation It's probably not rocket science to fix these (we would would just need to figure out a way to append them to each other), but it would prevent OpenJPA from working if we were to just merge the jars and overwrite same-named files. I've had this issue too. I wrote a small library (one class) in xbean to spin the /META-INF/services/ concept any way you like pretty much. This would cover the way you do things now: import org.apache.xbean.finder.ResourceFinder; ResourceFinder resourceFinder = new ResourceFinder(META-INF/ services/); ListClass classes = resourceFinder.findAllImplementations (org.apache.openjpa.conf.ProductDerivation.class); But you might consider making org.apache.openjpa.conf.ProductDerivation a directory that holds files that contain the implementation class names. Then you can have more than one in a jar. Here's an example directory: http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ src/test/resources/META-INF/java.net.URLStreamHandler/ Here's how you'd get your implementations: import org.apache.xbean.finder.ResourceFinder; ResourceFinder resourceFinder = new ResourceFinder(META-INF/); MapString, Class streamHandersMap = resourceFinder.mapAllImplementations(java.net.URLStreamHandler.class); You could just grab all the values from the map and be done with it. But the keys will the file name under META-INF/ java.net.URLStreamHandler/, which can be useful for all sorts of things. Here is the full test case: http://svn.apache.org/repos/asf/geronimo/ xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/finder/ ResourceFinderTest.java -David On Aug 15, 2006, at 12:46 PM, David Blevins wrote: On Aug 15, 2006, at 11:40 AM, Craig L Russell wrote: On Aug 15, 2006, at 11:06 AM, David Blevins wrote: On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote: Note that that will not merge anything you need in the META-INF directory. It does do it for plexus components.xml files though, so maybe it's a good time to make that pluggable. It'll definitely add the files from all the META-INF directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. So would it be easier to write a merge-manifest method or to restrict manifest services with the same name to one of the build modules? Sorry, I think I'm making things clear as mud :) I get the feeling we don't even have the issue Brett was mentioning. Aside from the MANIFEST.MF file itself, are there any jars of our own that contain the same file in the same place in the jar and those contents are different and need to be merged together? It's pretty easy to make a new MANIFEST.MF that better describes the new uber jar. -David
Re: Update version to SNAPSHOT
David- But you might consider making org.apache.openjpa.conf.ProductDerivation a directory that holds files that contain the implementation class names. Then you can have more than one in a jar. That would solve the problem, but since there is no generic classloader-based way of getting a list of resources beneath a certain directly, I would be uncomfortable with that approach, since it makes a lot of packaging assumption (it looks like it only works if the resources are stored in a top-level jar or on the file system). What if the resources are embedded in multiple levels of jars (like in a WAR or RAR)? Or what if an exotic custom classloader (common in EJB containers) is being used to load the classes that doesn't report a protocol in a way that ResourceFinder understands, or if it is using a network ClassLoader? Also, it will be nice to remain compatible with the upcoming JDK 1.6 java.util.ServiceLoader utility. It's probably safer just to manually append he services files, even though it requires writing something to manage the merging of the jars. On Aug 15, 2006, at 3:14 PM, David Blevins wrote: On Aug 15, 2006, at 12:56 PM, Marc Prud'hommeaux wrote: David- are there any jars of our own that contain the same file in the same place in the jar and those contents are different and need to be merged together? The only cases I know of are some of the files in services/. E.g.: openjpa-jdbc/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation openjpa-persistence-jdbc/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation openjpa-persistence/src/main/resources/META-INF/services/ org.apache.openjpa.conf.ProductDerivation It's probably not rocket science to fix these (we would would just need to figure out a way to append them to each other), but it would prevent OpenJPA from working if we were to just merge the jars and overwrite same-named files. I've had this issue too. I wrote a small library (one class) in xbean to spin the /META-INF/services/ concept any way you like pretty much. This would cover the way you do things now: import org.apache.xbean.finder.ResourceFinder; ResourceFinder resourceFinder = new ResourceFinder(META-INF/ services/); ListClass classes = resourceFinder.findAllImplementations (org.apache.openjpa.conf.ProductDerivation.class); But you might consider making org.apache.openjpa.conf.ProductDerivation a directory that holds files that contain the implementation class names. Then you can have more than one in a jar. Here's an example directory: http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ src/test/resources/META-INF/java.net.URLStreamHandler/ Here's how you'd get your implementations: import org.apache.xbean.finder.ResourceFinder; ResourceFinder resourceFinder = new ResourceFinder(META-INF/); MapString, Class streamHandersMap = resourceFinder.mapAllImplementations(java.net.URLStreamHandler.class); You could just grab all the values from the map and be done with it. But the keys will the file name under META-INF/ java.net.URLStreamHandler/, which can be useful for all sorts of things. Here is the full test case: http://svn.apache.org/repos/asf/ geronimo/xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/ finder/ResourceFinderTest.java -David On Aug 15, 2006, at 12:46 PM, David Blevins wrote: On Aug 15, 2006, at 11:40 AM, Craig L Russell wrote: On Aug 15, 2006, at 11:06 AM, David Blevins wrote: On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote: Note that that will not merge anything you need in the META-INF directory. It does do it for plexus components.xml files though, so maybe it's a good time to make that pluggable. It'll definitely add the files from all the META-INF directories into the resulting jar. I guess you are talking specifically about some pluggable strategy to merge two files of the same name such as two META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? Actually, I was thinking about META-INF/MANIFEST.MF and META-INF/services/*. But yes, merging of resources. Everything in META-INF/services/* will be copied into the new jar and you can redefine MANIFEST entries for the new jar using the same syntax as for the maven-jar-plugin. But it won't intelligently concatenate the contents of individual matching files from the source jars as I assume Brett was referring to with the plexus components.xml. So would it be easier to write a merge-manifest method or to restrict manifest services with the same name to one of the build modules? Sorry, I think I'm making things clear as mud :) I get the feeling we don't even have the issue Brett was mentioning. Aside from the MANIFEST.MF file itself, are there any jars of our own that contain the same file in the same place in the jar and those contents are
Re: Update version to SNAPSHOT
This discussion would be great to capture on the wiki for the time (not too far away) when we will actually package and ship some code. Craig On Aug 15, 2006, at 7:20 PM, David Blevins wrote: On Aug 15, 2006, at 7:42 AM, Craig L Russell wrote: On Aug 15, 2006, at 6:38 AM, Patrick Linskey wrote: Check out the Assembly plugin and it's predefined jar-with-dependencies descriptor[1]. I'm pretty sure that most people using Maven will just have a runtime dependency on the core OpenJPA library and be done with it, but it's always nice for Ant users. Exactly -- mvn users will use the dependencies, but people who want to download and use the distribution directly may not want a billion little jars. Yes, my experience says it's ok to have 10 dependencies on e.g. commons-logger, antlr, etc. but having 10 dependencies on openjpa- kernel4, openjpa-kernel5, openjpa-api, openjpa-blah is annoying. So if possible, I'd also like to have a jar with all the stuff in it. That'd be nice. Some jar that contains all the openjpa-*.jar files is perfect for my needs. The good news is that the maven-assembly- plugin allows you to define several assembly xml files and build multiple archives containing whatever you like. So if people want, we could have: openjpa-0.9.0-full.jar // contains all openjpa code, openjpa- *.jars merged openjpa-0.9.0-nodep.jar // contains all openjpa code and all third party dependency jars There's a naming convention for this kind of thing, hope I've got it right. -David Craig -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. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: Update version to SNAPSHOT
I spoke to Geir about this a bunch last week; he suggested we use a number-dev nomenclature, so that it'd be clear that the current build is a dev build rather than a well-known numbered release. So, this would mean we'd have 0.9.0-dev, meaning that there are differences since the 0.9.0 release itself. Ok, well I don't want to cause problems if it's a done deal. Just a couple FYIs, maven will still treat that as a final version -- once downloaded, it won't check for newer versions. Also, maven will consider 0.9.0 to be greater than 0.9.0-dev. What's the difference between SNAPSHOT and -dev, in mavenese? I wasn't suggesting that what we talked about was better; just tossing some more fuel on the fire. Also, does anyone know what's involved in making snapshots happen on a regular basis (say, nightly iff an svn change happened that day)? With a couple patches to your root pom I can hook you up to Apache's Continuum install on vmbuild.apache.org (very slow but works). Publishing jars from there is still a bit tricky, but we might be able to figure something out. We've got a TeamCity server up and running at BEA (working on getting one in the DMZ...); it publishes artifacts. So, we could probably do something to get it to rsync the built artifacts somewhere or something like that. -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: Update version to SNAPSHOT
Hi Marc, On Aug 14, 2006, at 6:53 PM, Marc Prud'hommeaux wrote: Patrick- What's the difference between SNAPSHOT and -dev, in mavenese? I wasn't suggesting that what we talked about was better; just tossing some more fuel on the fire. I don't know how well documented it is, but my understanding is that the -SNAPSHOT suffix (which, I believe, is automatically appended if some snapshot=true attribute is set in the pom.xml) is treated specially: when resolving dependencies, rather than re- using the cached jars for any SNAPSHOT-suffix'd jars, Maven will re- download it every time (or, at least, check to make sure the cached version is the most recent one). This is handy for nightlies and things like that, since you don't want to have to up the version every single time, but you do want people who are developing against snapshots to always have the latest version. At least that's my understanding. Agrees with mine. So if you have a xxx-0.9.0-dev, maven considers that to be a fixed release and won't automatically update it (ever). If you want to refresh it, you manually delete your cached version and when maven can't find it, maven will download new bits. Or you mvn install xxx and if xxx has to be rebuilt, the install goal replaces the bits in your local repository. If you have a 0.9.0-SNAPSHOT, maven will always try to download the latest copy on every invocation of maven. If you prefer that maven not do this, run maven with the -o option and it won't try to download new versions of SNAPSHOT. Usually, SNAPSHOT builds are not published, so maven never finds the SNAPSHOT build in your remote repositories. It might be good to run through the common dev scenarios in detail to see which model would work best for this project, since there are so many sub-projects. Craig On Aug 14, 2006, at 6:43 PM, Patrick Linskey wrote: I spoke to Geir about this a bunch last week; he suggested we use a number-dev nomenclature, so that it'd be clear that the current build is a dev build rather than a well-known numbered release. So, this would mean we'd have 0.9.0-dev, meaning that there are differences since the 0.9.0 release itself. Ok, well I don't want to cause problems if it's a done deal. Just a couple FYIs, maven will still treat that as a final version -- once downloaded, it won't check for newer versions. Also, maven will consider 0.9.0 to be greater than 0.9.0-dev. What's the difference between SNAPSHOT and -dev, in mavenese? I wasn't suggesting that what we talked about was better; just tossing some more fuel on the fire. Also, does anyone know what's involved in making snapshots happen on a regular basis (say, nightly iff an svn change happened that day)? With a couple patches to your root pom I can hook you up to Apache's Continuum install on vmbuild.apache.org (very slow but works). Publishing jars from there is still a bit tricky, but we might be able to figure something out. We've got a TeamCity server up and running at BEA (working on getting one in the DMZ...); it publishes artifacts. So, we could probably do something to get it to rsync the built artifacts somewhere or something like that. -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. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: Update version to SNAPSHOT
It might be good to run through the common dev scenarios in detail to see which model would work best for this project, since there are so many sub-projects. Good point. I think that we should move to a model where we have a project that assembles a single unified jar (including merging contents of META-INF files). This seems much more conducive to most normal uses of OpenJPA; I think that the sub-projects should be there for advanced users and as an internal artifact of how the product is designed and built. Does anyone know of existing mvn technology to merge resource files? To easily assemble jars together? -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. smime.p7s Description: S/MIME cryptographic signature
RE: Update version to SNAPSHOT
On Mon, 2006-08-14 at 20:57 -0700, Patrick Linskey wrote: It might be good to run through the common dev scenarios in detail to see which model would work best for this project, since there are so many sub-projects. Good point. I think that we should move to a model where we have a project that assembles a single unified jar (including merging contents of META-INF files). This seems much more conducive to most normal uses of OpenJPA; I think that the sub-projects should be there for advanced users and as an internal artifact of how the product is designed and built. Does anyone know of existing mvn technology to merge resource files? To easily assemble jars together? Check out the Assembly plugin and it's predefined jar-with-dependencies descriptor[1]. I'm pretty sure that most people using Maven will just have a runtime dependency on the core OpenJPA library and be done with it, but it's always nice for Ant users. [1]: http://maven.apache.org/plugins/maven-assembly-plugin/predefined.html -- Trygve
Re: Update version to SNAPSHOT
Note that that will not merge anything you need in the META-INF directory. It does do it for plexus components.xml files though, so maybe it's a good time to make that pluggable. - Brett On 15/08/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: On Mon, 2006-08-14 at 20:57 -0700, Patrick Linskey wrote: It might be good to run through the common dev scenarios in detail to see which model would work best for this project, since there are so many sub-projects. Good point. I think that we should move to a model where we have a project that assembles a single unified jar (including merging contents of META-INF files). This seems much more conducive to most normal uses of OpenJPA; I think that the sub-projects should be there for advanced users and as an internal artifact of how the product is designed and built. Does anyone know of existing mvn technology to merge resource files? To easily assemble jars together? Check out the Assembly plugin and it's predefined jar-with-dependencies descriptor[1]. I'm pretty sure that most people using Maven will just have a runtime dependency on the core OpenJPA library and be done with it, but it's always nice for Ant users. [1]: http://maven.apache.org/plugins/maven-assembly-plugin/predefined.html -- Trygve -- Apache Maven - http://maven.apache.org Better Builds with Maven book - http://library.mergere.com/
