Re: Unintended usage of core plugin stubs
On 24-Sep-08, at 7:53 AM, Benjamin Bentmann wrote: Jason van Zyl wrote: On 23-Sep-08, at 10:50 PM, Benjamin Bentmann wrote: As releasing the stub plugins would increase their potential to trouble unaware users How so? The problem I originally described was about users that referred to LATEST plugin version and had the snapshot repo enabled. I think we're going to have two major user stories here, people who take the last released IT bundle and run it to validate and people who check out the sources and build everything and run the ITs. If we release this stuff often enough there will only be a few ITs in flux at any given moment. We cannot leave references to snapshot anything in the ITs for long. If we deploy the stubs to central, all users that haven't locked down the plugin version have a chance of getting the stub, even if they don't use snapshots. E.g. releasing maven-clean-plugin:0.1-stub would make the stub considered LATEST over maven-clean-plugin:2.2. I could imagine we would receive a lot more user complains then. Like I said in our own ITs using snapshot versions of the stubs I don't think makes a lot of sense. The stub is in such a high degree of flux we can't release it? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing runtime plugin config from a MOJO.
I guess you could navigate from MavenProject, search the plugins for the one that matches and then dig into the config section... sounds messy though... and you might have to either abort or dif through pluginManagement if there are issues also you'd need to decide what to do when people use multiple executions for surefire 2008/9/24 Nick Pellow [EMAIL PROTECTED] Hi, I am writing a custom maven2 MOJO. I need to access the runtime configuration of another plugin, from this MOJO. What is the best way to do this? A concrete example: I would like to access any user defined excludes and includes patterns of the maven-surefire-plugin from my MOJO. Cheers, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unintended usage of core plugin stubs
Jason van Zyl wrote: I think we're going to have two major user stories here, people who take the last released IT bundle and run it to validate and people who check out the sources and build everything and run the ITs. Not sure you fully understand the problem I was referring to. There is a third party of users affected by the stub plugins: Those that do their regular builds (i.e. at work and completely unrelated to our ITs) and don't follow the best practice of locking down plugin versions. Those users will encounter problems with their builds because of getting the stub versions (when the repo marks them as latest). While I don't consider their potential build problems due to using the stubs to be our fault, I believe it's advisable to shield the stubs from the normal users as John suggested to prevent rant or bug reports towards Maven like seemed to have happend after infra purged the snapshot repo. Like I said in our own ITs using snapshot versions of the stubs I don't think makes a lot of sense. Agreed. The stub is in such a high degree of flux we can't release it? I consider those particular core plugin stubs quite stable. If you look at their code, they basically create a touch file to allow checking by the Verifier that the goal was run. The stubs aren't meant to mimic the real plugins in any other way. Dependency resolution, forking or whatever the real plugins do and we might want to test should be handled by other IT plugins, again as John previously suggested to keep IT plugins easy to understand and maintainable. So their current impl shouldn't change (unless for bugfixing). Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unintended usage of core plugin stubs
On 24-Sep-08, at 10:02 AM, Benjamin Bentmann wrote: Jason van Zyl wrote: I think we're going to have two major user stories here, people who take the last released IT bundle and run it to validate and people who check out the sources and build everything and run the ITs. Not sure you fully understand the problem I was referring to. There is a third party of users affected by the stub plugins: Those that do their regular builds (i.e. at work and completely unrelated to our ITs) and don't follow the best practice of locking down plugin versions. Those users will encounter problems with their builds because of getting the stub versions (when the repo marks them as latest). We can either prevent the mixups by running the ITs in an isolated local repository -- which I think would be a good idea -- or figure something out with the versions. This is not much different then someone working with a branch of a set of dependencies against a stable stream. Bundling up a bunch of stuff in a zip really defeats the purpose of being able to easy deploy to a repository, share and test. We have to be able to come up with a better way to partition this then create a custom package. While I don't consider their potential build problems due to using the stubs to be our fault, I believe it's advisable to shield the stubs from the normal users as John suggested to prevent rant or bug reports towards Maven like seemed to have happend after infra purged the snapshot repo. Like I said in our own ITs using snapshot versions of the stubs I don't think makes a lot of sense. Agreed. The stub is in such a high degree of flux we can't release it? I consider those particular core plugin stubs quite stable. If you look at their code, they basically create a touch file to allow checking by the Verifier that the goal was run. The stubs aren't meant to mimic the real plugins in any other way. Dependency resolution, forking or whatever the real plugins do and we might want to test should be handled by other IT plugins, again as John previously suggested to keep IT plugins easy to understand and maintainable. So their current impl shouldn't change (unless for bugfixing). Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No more uber jar
On 23/09/2008, at 11:57 PM, Igor Fedorenko wrote: Would not it be better to move wagons and anything else not intended to be visible by plugins into a separate classloader? I believe that is essentially what the container changes on trunk did. Whether it's something along those lines or a simpler alternative that keeps the current extension semantics, this would certainly be better, but shading them might be simpler and more consistent with current behaviour in the short term. Cheers, Brett Brett Porter wrote: /me cheers Yep, go for it. This will also mean producing shaded versions of the wagons though I think, or creating a shaded built-in wagons JAR, to prevent some of their dependencies being forced on plugins. The ITs for MNG-3581/3599 might pick this up, but it would be worth an extra IT to verify. Cheers, Brett On 23/09/2008, at 3:00 AM, Jason van Zyl wrote: I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MAVEN-SUREFIRE: Incomplete uploading
Hi Joakim (and all), I'm compiling my application with maven2 and I get this error: Reason: Unable to download the artifact from any repository org.apache.maven.surefire:surefire:pom:2.5-SNAPSHOT I can see on http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-surefire-plugin/ that you have uploaded a new version of maven-surefire-plugin (2.5-SNAPSHOT) but you haven't uploaded all the things. At the header of http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-surefire-plugin/2.5-SNAPSHOT/maven-surefire-plugin-2.5-20080923.191343-1.pom file appears a reference to a inexistent pom. - # parent artifactIdsurefire/artifactId groupId*org.apache.maven.surefire*/groupId version2.5-SNAPSHOT/version /parent Can you upload it please? Thanks in advance! Enric Nota Legal: Este correo electrónico puede contener información estrictamente confidencial y es de uso exclusivo del destinatario, quedando prohibida a cualquier otra persona su revelación, copia, distribución, o el ejercicio de cualquier acción relativa a su contenido. Si ha recibido este correo electrónico por error, por favor, conteste al remitente, y posteriormente proceda a borrarlo de su sistema. Gracias por su colaboración. Confidentiality notice: This e-mail message may contain confidential and/or legally privileged information and is solely for the attention and use of the intended recipient. Any disclosure, copying, distribution or the taking of any action with relation to the contents of this e-mail by any other person is strictly prohibited. If you believe that this e-mail has been mistakenly sent to you, please reply to the sender from whom you received the message in error and then delete the original e-mail from your system. Thank you for your co-operation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MAVEN-SUREFIRE: Incomplete uploading
Enric Albiach wrote: I'm compiling my application with maven2 and I get this error: Reason: Unable to download the artifact from any repository org.apache.maven.surefire:surefire:pom:2.5-SNAPSHOT The upload is in progress. I apologize for this inconvenience, I hadn't checked whether the other artifacts had been deployed before. Out of curiosity, were you doing a production build that triggered download of this SNAPSHOT? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No more uber jar
I have simple i don't want to export this working in ClassWorlds now so I will attempt to integrate that after doing some testing with Oleg in integrating Mercury. On 23-Sep-08, at 3:57 PM, Igor Fedorenko wrote: Would not it be better to move wagons and anything else not intended to be visible by plugins into a separate classloader? Brett Porter wrote: /me cheers Yep, go for it. This will also mean producing shaded versions of the wagons though I think, or creating a shaded built-in wagons JAR, to prevent some of their dependencies being forced on plugins. The ITs for MNG-3581/3599 might pick this up, but it would be worth an extra IT to verify. Cheers, Brett On 23/09/2008, at 3:00 AM, Jason van Zyl wrote: I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No more uber jar
Awesome! Let's put it up with doco, etc. on the 2.2.x release plan, wdyt? Jason van Zyl wrote: I have simple i don't want to export this working in ClassWorlds now so I will attempt to integrate that after doing some testing with Oleg in integrating Mercury. On 23-Sep-08, at 3:57 PM, Igor Fedorenko wrote: Would not it be better to move wagons and anything else not intended to be visible by plugins into a separate classloader? Brett Porter wrote: /me cheers Yep, go for it. This will also mean producing shaded versions of the wagons though I think, or creating a shaded built-in wagons JAR, to prevent some of their dependencies being forced on plugins. The ITs for MNG-3581/3599 might pick this up, but it would be worth an extra IT to verify. Cheers, Brett On 23/09/2008, at 3:00 AM, Jason van Zyl wrote: I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No more uber jar
Should work but I've been testing it with trunk ... I would have to restore some classes to make it work on the branch but I'll look. On 24-Sep-08, at 5:41 PM, John Casey wrote: Awesome! Let's put it up with doco, etc. on the 2.2.x release plan, wdyt? Jason van Zyl wrote: I have simple i don't want to export this working in ClassWorlds now so I will attempt to integrate that after doing some testing with Oleg in integrating Mercury. On 23-Sep-08, at 3:57 PM, Igor Fedorenko wrote: Would not it be better to move wagons and anything else not intended to be visible by plugins into a separate classloader? Brett Porter wrote: /me cheers Yep, go for it. This will also mean producing shaded versions of the wagons though I think, or creating a shaded built-in wagons JAR, to prevent some of their dependencies being forced on plugins. The ITs for MNG-3581/3599 might pick this up, but it would be worth an extra IT to verify. Cheers, Brett On 23/09/2008, at 3:00 AM, Jason van Zyl wrote: I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven release plugin
Someone wants to take the lead ? there are 2 issues to fix in the roadmap Arnaud On Wed, Sep 24, 2008 at 6:36 PM, Zucchi Alessandro [EMAIL PROTECTED] wrote: Olivier Lamy said: Hi, Personnaly, I have planned to do it near end of September. I hope will be so. Bye Remy Sanlaville wrote: Hi, ping: Someone know when the 2.0-beta-8 of maven release plugin will be released ? We are really waiting for it. Thanks, Rémy -- View this message in context: http://www.nabble.com/Maven-release-plugin-tp19269992p19652882.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: No more uber jar
If you're talking about migrating that change back to an older version of plexus/classworlds for the 2.2.x branch, I've been thinking of doing a write-up to migrate off of plexus 1.0-alpha-9 and make it up to date with the current plexus work. Given that, would you still have to backport things? -john Jason van Zyl wrote: Should work but I've been testing it with trunk ... I would have to restore some classes to make it work on the branch but I'll look. On 24-Sep-08, at 5:41 PM, John Casey wrote: Awesome! Let's put it up with doco, etc. on the 2.2.x release plan, wdyt? Jason van Zyl wrote: I have simple i don't want to export this working in ClassWorlds now so I will attempt to integrate that after doing some testing with Oleg in integrating Mercury. On 23-Sep-08, at 3:57 PM, Igor Fedorenko wrote: Would not it be better to move wagons and anything else not intended to be visible by plugins into a separate classloader? Brett Porter wrote: /me cheers Yep, go for it. This will also mean producing shaded versions of the wagons though I think, or creating a shaded built-in wagons JAR, to prevent some of their dependencies being forced on plugins. The ITs for MNG-3581/3599 might pick this up, but it would be worth an extra IT to verify. Cheers, Brett On 23/09/2008, at 3:00 AM, Jason van Zyl wrote: I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No more uber jar
I don't know if it's worth trying to upgrade the container. I tried for a couple days and gave up. I'm not really sure it's worth the effort. I think classworlds would be a few hours work and very doable. On 24-Sep-08, at 7:15 PM, John Casey wrote: If you're talking about migrating that change back to an older version of plexus/classworlds for the 2.2.x branch, I've been thinking of doing a write-up to migrate off of plexus 1.0-alpha-9 and make it up to date with the current plexus work. Given that, would you still have to backport things? -john Jason van Zyl wrote: Should work but I've been testing it with trunk ... I would have to restore some classes to make it work on the branch but I'll look. On 24-Sep-08, at 5:41 PM, John Casey wrote: Awesome! Let's put it up with doco, etc. on the 2.2.x release plan, wdyt? Jason van Zyl wrote: I have simple i don't want to export this working in ClassWorlds now so I will attempt to integrate that after doing some testing with Oleg in integrating Mercury. On 23-Sep-08, at 3:57 PM, Igor Fedorenko wrote: Would not it be better to move wagons and anything else not intended to be visible by plugins into a separate classloader? Brett Porter wrote: /me cheers Yep, go for it. This will also mean producing shaded versions of the wagons though I think, or creating a shaded built-in wagons JAR, to prevent some of their dependencies being forced on plugins. The ITs for MNG-3581/3599 might pick this up, but it would be worth an extra IT to verify. Cheers, Brett On 23/09/2008, at 3:00 AM, Jason van Zyl wrote: I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hi there,
as often I a little late on some threads ;)
I have start a proposal [1]
so far so good.
I have the following suggestions:
1. Also specify that the pom.filters are in the order of their declaration in
the XML.
2. Resolve variables whenever they are requested.
What I mean is that I can do
filter1.properties:
var1=Foo
var3=${var2}/Thing
filter2.properties:
var2=${var1}-Bar
So if I resolve ${var3} I get Foo-Bar/Thing.
That would be an excellent feature, since I am using
maven for deploying a large system and therefore
build it as multiple debian-packages with
seperation of application- and configuration-packages.
The configuration packages are build for
production as well as for 14 different
testing-environments. Various ports, hostnames, etc.
slightly differ in these environments. I could avoid
a lot of redundancies and daramtically simplify my
filters with the features described above.
Do I need to file a JIRA ticket or is this enough
input?
My suggestion to implement this, would be to
create chains of Properties that inherit
from their parent and resolve this in
getProperty(). However you might not want to
use your own API defined as clean interface
instead of Properties.
Thanks
Jörg
Thanks for comments,
--
Olivier
[1]
http://docs.codehaus.org/display/MAVEN/Resources+Handling+(common+component+maven-filtering)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI2pjzmPuec2Dcv/8RAj+JAJ9CuWvkh8A+UbHxgJfksaIPQbT5hQCfete7
XejVhEEoWmQxfpIvgoLLJJ4=
=xaPy
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XBean and DI?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, The additions Dain has made to XBean adds things I was just never interested in like constructor injection and bean factories. Also xbean-reflect thinks in java.lang.reflect.Type terms so it's easy to add converters that are generics-aware. For example I recently added converters for MapK,V and SetT and ListT and it only took an hour. I spent the last year with creating support for this. You have to rebuild all the stuff that is in javac but missing in the JDK. The erasure was maybe the only way to introduce generics but it is a real pain. I almost got braindead with this. Is ? super CharSequence.isAssignableFrom(? super String) or vice versa? Could not find the time to have a look at XBean but I doubt its doing the stuff right with java.lang.reflect.Type. Please let me know if I am wrong. Write some class Foo extends ListString and then BarE extends Foo further Some extends BarInteger. Now let me know if XBean tells you that Some.get(int) has the return-type String. My implementation does... Maybe you want to have a look. However still in progress of improving, so you might NOT want to use it now... https://m-m-m.svn.sourceforge.net/svnroot/m-m-m/trunk/mmm-util/mmm-util-core/src/main/java/net/sf/mmm/util/reflect/api/GenericType.java Site has NOT be updated for a while but also http://m-m-m.sourceforge.net/maven/mmm-util/mmm-util-core/index.html http://m-m-m.sourceforge.net/maven/mmm-util/mmm-util-pojo/index.html Just in general the code is pretty small and tight as well and generally very easy to add features. -David Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI2p5PmPuec2Dcv/8RApPgAJ9n5f9eeNVBVukFTx6vFThacyI/0gCcDPyw tNxIS2JZbqwtmcV8JkZCV2A= =3ikU -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
2008/9/24 Joerg Hohwiller [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hi there,
as often I a little late on some threads ;)
I have start a proposal [1]
so far so good.
I have the following suggestions:
1. Also specify that the pom.filters are in the order of their declaration in
the XML.
They are not used (as they are not used in resources plugin 2.2 and
adding filters as a child of the project element is not valid).
2. Resolve variables whenever they are requested.
What I mean is that I can do
filter1.properties:
var1=Foo
var3=${var2}/Thing
filter2.properties:
var2=${var1}-Bar
So if I resolve ${var3} I get Foo-Bar/Thing.
That would be an excellent feature, since I am using
maven for deploying a large system and therefore
build it as multiple debian-packages with
seperation of application- and configuration-packages.
The configuration packages are build for
production as well as for 14 different
testing-environments. Various ports, hostnames, etc.
slightly differ in these environments. I could avoid
a lot of redundancies and daramtically simplify my
filters with the features described above.
Do I need to file a JIRA ticket or is this enough
input?
No because it already works (there is an it[1] for this in the
resources plugin).
Thanks,
--
Olivier
[1]
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-resources-plugin/src/it/filter/
My suggestion to implement this, would be to
create chains of Properties that inherit
from their parent and resolve this in
getProperty(). However you might not want to
use your own API defined as clean interface
instead of Properties.
Thanks
Jörg
Thanks for comments,
--
Olivier
[1]
http://docs.codehaus.org/display/MAVEN/Resources+Handling+(common+component+maven-filtering)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI2pjzmPuec2Dcv/8RAj+JAJ9CuWvkh8A+UbHxgJfksaIPQbT5hQCfete7
XejVhEEoWmQxfpIvgoLLJJ4=
=xaPy
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven archetype plugin version 2.0-alpha-4
Any PMC member? There still 24H left to vote. Regards, Raphaël 2008/9/23, nicolas de loof [EMAIL PROTECTED]: +1 2008/9/22 Raphaël Piéroni [EMAIL PROTECTED] Hi, We solved 19 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095styleName=Htmlversion=14253 Staging repo: http://people.apache.org/~rafale/archetype-stage-repository/ Beware of MNG-2974, a workaround is currently to use a repository manager. Staging site: http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-4/ Sync not made at writing time, meanwhile please use http://people.apache.org/~rafale/site/maven-archetype-plugin/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Regards, Raphaël Piéroni
