Re: Artifact.getVersion()
I found the solution casually looking at the source code of the surefile plugin : [quote] surefireArtifact.isSnapshot(); // TODO: this is ridiculous, but it fixes getBaseVersion to be -SNAPSHOT if needed [/quote] And yes, it seems to work! :) Simone Brian E. Fox wrote: It's SNAPSHOT when resolved from the local repo and timestamped when it comes from the remote. There's a method to get SNAPSHOT, I think it's something like getBaseVersion(). I had to deal with this also in the dependency and enforcer plugins. -Original Message----- From: Simone Gianni [mailto:simo...@apache.org] Sent: Sunday, January 18, 2009 11:34 AM To: Maven Developers List Subject: Artifact.getVersion() Hi all, I already posted this on the users list some weeks ago, but got no answer, so I'm asking here. I'm writing a Maven plugin in which I'm using Artifact.getVersion on dependencies. When applied to a dependency which is a snapshot, sometimes the returned version is 0.0.1-SNAPSHOT (which is the version declared both in the dependency in the pom and in the version of the artifact pom), other times it returns the complete snapshot version, like 0.0.1-20090107-etcetc . Since this behavior is not consistent, I think it is related to some kind of "timeout". When the snapshot is timed out (and maven checks the repository for new versions) then getVersion returns the timestamped version, otherwise it returns the 0.0.1-SNAPSHOT version. Since I'm generating some files based on the artifact group, name AND version, this random behavior causes malfunctions. Is there a way to always retrieve either the generic "0.0.1-SNAPSHOT" or the "0.0.1-etcetc" version? I can see a number of getXVersion methods on Artifact, but have no idea which one will remain stable, are them documented somewhere? Thanks in advance, Simone -- Simone GianniCEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Artifact.getVersion()
Hi all, I already posted this on the users list some weeks ago, but got no answer, so I'm asking here. I'm writing a Maven plugin in which I'm using Artifact.getVersion on dependencies. When applied to a dependency which is a snapshot, sometimes the returned version is 0.0.1-SNAPSHOT (which is the version declared both in the dependency in the pom and in the version of the artifact pom), other times it returns the complete snapshot version, like 0.0.1-20090107-etcetc . Since this behavior is not consistent, I think it is related to some kind of "timeout". When the snapshot is timed out (and maven checks the repository for new versions) then getVersion returns the timestamped version, otherwise it returns the 0.0.1-SNAPSHOT version. Since I'm generating some files based on the artifact group, name AND version, this random behavior causes malfunctions. Is there a way to always retrieve either the generic "0.0.1-SNAPSHOT" or the "0.0.1-etcetc" version? I can see a number of getXVersion methods on Artifact, but have no idea which one will remain stable, are them documented somewhere? Thanks in advance, Simone -- Simone GianniCEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: can anybody familiar with dependency plugin help me out?
Hi 陈思淼 , I'm not sure about it (never tried to use that specific component), but since it is a component of the underlying Plexus container, simply "annotating" it with @component should trigger Plexus to inject the current instance. You could take a look at this : http://plexus.codehaus.org/writing-components-trail/07_01_implementing_monitor_mojo.html Hope this helps, Simone 陈思淼 wrote: > Im trying to do my own dependence validator,I need to know how the > Maven dependency Tree Organized.I read the dependency:tree source code and I > don't know How This kind of code works,: > > >> /** >> >> > * The dependency tree builder to use. > > * > > * @component > > * @required > > * @readonly > > */ > > private DependencyTreeBuilder dependencyTreeBuilder; > > > how can the DependencyTreeBuilder inject to my own plugin, > can you help me out? > thank you very much! > > -- Simone GianniCEO Semeru s.r.l. Apache Committer MALE human being programming a computer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Someone know Maven core Mechanism please help.
Hi 陈思淼, I'm not a Maven developer but I did a custom packaging. You have to follow these steps : - Create a plugin (mojo) project - In this plugin project, define your plugins, with their goals. For example, one of them could be jcar-compile - In the src/main/resources of your plugin, create the folder META-INF/plexus/ - In this folder, create a file components.xml - In this file, you can add directives to the Plexus container. The syntax is nearly the same used in Avalon, if you ever used Avalon or Cocoon 2.1 you should be familiar with it. - In our case, you can declare which phases are required for your custom packaging type, and the binding between phases and plugins (either the default one and your custom). - You can find the components.xml for my custom packaging here http://svn.apache.org/repos/asf/labs/magma/trunk/maven-magma-plugin/src/main/resources/META-INF/plexus/components.xml ... In my case my packaging name is "magma" ... As you can see, i customized compilem, test-compile and test phases - In projects packaged with you custom packages you have to : ... Set to your packaging name ... Include you plugin in the plugins section of the pom, specifying true ... You can find an example of a package using my custom packaging here http://svn.apache.org/repos/asf/labs/magma/trunk/foundation-basics/pom.xml .. Maybe this last step could be avoidable somehow? maybe using some naming convention? At this point, install your plugin, and try to install an artifact using your custom packaging. I'm pretty sure I forgot something important, but this should at least give you a starting point. Unfortunately I cannot remember where I found this informations, but there is a guide somewhere on the Maven site. Hope this helps, Simone 陈思淼 wrote: > I want to define a new packaging type called jcar to package my own project. > I traced the source core of maven and that the Maven-core will look up for > componentManagerManager by the key > "org.apache.maven.lifecycle.mapping.LifecycleMapping"+packaging_type, > Im sure the default packaging type "jar,ear,rar" for example, have > registered to the PlexusContainer. but I don't know how and when to > registered that LifecycleMapping componentManager to the container? and how > I can I do it myself? > Is there Maven plugin developer can tell me some detail about this? > Thank you very Much. > > -- Simone GianniCEO Semeru s.r.l. Apache Committer MALE human being programming a computer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XBean and DI?
Hi all, sorry for jumping in and maybe being off topic, but the problem of generics erasure and reflection also bugged me in my Apache Lab, and I also came up with a small library to avoid reinventing the wheel any time, and was recently proposing it to people in Apache Commons. They said that there could be space for such a thing in commons-lang, and I feel that if there is a place in ASF for such utility stuff is in commons. You can find the thread here : http://www.nabble.com/-all--Generics-and-Return-Type--tt16595948.html#a19605981 I don't know how much this is related, cause I don't know Xbeans to understand if the connection is proper, but seems like many of us are working on very similar stuff, and we could join the effort. Simone Jason van Zyl wrote: > I suggest you both talk to Dain and see about integrating it into > XBean. XBean is used for all of Geronimo's EE injection and Dain/David > are pretty thorough. I'm not planning on using anything else on trunk. > > On 25-Sep-08, at 10:15 AM, Mark Hobson wrote: > >> 2008/9/24 Joerg Hohwiller <[EMAIL PROTECTED]>: >>>> 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 Map and Set and List 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 .isAssignableFrom() >>> or vice versa? >> >> FWIW, I've written a small library here internally for working with >> Types that: >> >> - provides a factory to create the various incarnations >> - implements isAssignable and other useful Class methods for Types >> - formats and parses Types to and from Strings >> - provides type literals (like Guice's TypeLiteral) >> >> I agree this kind of code should be available in the JDK to prevent >> people from reinventing the wheel. If there's any interest I could >> look into open-sourcing it? >> >> Cheers, >> >> Mark >> >> - >> 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 unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Simone GianniCEO Semeru s.r.l. Apache Committer MALE human being programming a computer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
Hi Nicolas, yes, many Maven plugins have an Eclipse counterpart, and having the eclipse plugin discover this plugins and delegate to them the generation of eclipse specific configurations is a great idea. I don't know the internals of the Eclipse plugin well enough to understand the details of your proposal, but it sounds very interesting. Any comment from the Maven community? Just to name a few, these are the technologies that i use extensively and have both maven and eclipse support that could be harmonized: - Obviously the java compiler itself :) - The Maven eclipse plugin - AspectJ - Hibernate - Spring - Jetty (would it be possible to make some generation of configurations for Eclipse WST?) - Emma, Clover - FindBugs Which else? Simone nicolas de loof wrote: > Hello, > > I'd like to propose an extension mecanism for the Eclipse plugin (and > potentially for other plugins). > > The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted > the dependency resolution code from eclipse plugin. This was required to > create the .tomcatPlugin configuration file. > If this plugin code could execute *inside* the eclipse plugin as an > EclipseWriter it could benefict from the original code, and also from plugin > updates. > > I propose to add a new extensibility feature in the eclipse plugin. Using a > new parameter, or maybe by searching some "extension" file in the plugin > classpath, the eclipse plugin could setup a list of external EclipseWriters > to run. > > sample configuration : > > > maven-eclipse-plugin > > ... > > > sysdeo-tomcat > > > > > > > > > > org.codehaus.mojo > sysdeo-tomcat-maven-plugin > x > > > > > > > Beeing added to the plugin classpath, the "plugin-extension" could add it's > EclipseWriters, and maybe other optional components (to setup ProjectNatures > ?). > > Many other extensions could be added this way to the eclipse plugin : > generate SpringIDE configuration, setup Checkstyle in sync with the > maven-checkstyle configuration, etc. > > Another benefict is that the "extension" could benefict from the forked > generate-source execution that the eclipse-plugin runs, to access the list > of multi-project modules. > > > Any suggestion is welcome. > > Nicolas. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Kenney Westerhof wrote: > The real problem is that people want an unpacked artifact, probably > since packaging > a war artifact is too slow (lots of dependencies copied, and zipping > up zips is slow). More or less, in the parallel thread "Manipulating the WAR directory before the WAR file gets built" the problem is not to optimize build time, but actually to be able to write plugins that can operate on the WAR file before it is generated. Obviously this could be solved by generating the war, reopening it, manipulating it, reassemboling it, but if this is the only solution then maybe even my stupid patch (http://jira.codehaus.org/browse/MWAR-86 ) can prove useful. > > If we require everyhing to be present in target/ prior to the package > phase, then the > package phase would just zip it up, as it was intended to with 'jar' > packagings. Yep, IMO this is it. > > A solution for this case would be to not allow any code in war > projects; everything that goes in /WEB-INF/classes > should just be in a dependency placed in /WEB-INF/lib. Then, the war > packaging would be simplified to not filter-copy src/main/resources to > the archive root; this is then handled during the normal resources > phases. No more src/main/webapp. What it does right now is correct, > though: src/main/resources should end up in the classpath. I'm > proposing a change > to deal with 'war' project resources differently. > Also, overlaying could be handled in generate-resources. generate-resources is intended to generate something in the target folder? or in the src folders? cause, if it's intended to generate in the target then there is no problem at all, is the perfect phase to do everything (overlay the war, pack all the stuff in the target folder, manipulate it with third party plugins) and the package can simply zip it. I'm asking this because in http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html it's not specified, and its companion phase generate-sources seems to mean "generate spacial sources like ejb distribution code or rmi stubs in src/main/java so that the default compile system will compile them". > Then, if we allow the package phase to include other dependencies, > like how it's done in the ear plugin, the war > problem is solved. If you want an unpacked war, you can call the > non-lifecycle mojo unpacked-war > (or whatever it's called), that also @execute phase='test'. In the case of third party plugin that needs to work on a war before it's packed, the work of this third party plugin could be (as it is for the cocoon deployer plugin) part of the normal build/package/install cycle of the application, so placing this in a non-lifecycle step is not a (good) solution. > > I'd like to gather all use cases that would benefit from a > 'prepare-package' phase, and see if there are solutions that don't > require lifecycle phases. As Jason said, it will > be something that we can never take back. Also, most packaging mojo's > would require re-wiring to that phase and leave the 'zipping up' to a > simple mojo bound to 'package'. See my email "Re: Manipulating the WAR directory before the WAR file gets built" of 2006-12-04 @17:24 for some usecases I have encountered. Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Steve Loughran wrote: > The thing to remember about WAR files is that they are a packaging > format that is intended to make it easy to deploy web apps. Not > distribute, but deploy. The old WAR/EAR use cases always had the > 'assembler' who would be some person who would somehow assemble WARs > and EJB beans to make a working app, presumably through some GUI that > required the same work to be repeated every release. > > If you are doing lots of late binding tuning to the WAR file, then > perhaps build time is the wrong place to do it; it should really be > done as part of the deployment process, where per machine > optimisations can go in. In this world what you want from the outset > is the exploded WAR, which is then taken with server-specific options > to create the target WAR for the target system. It's not late binding tuning with custom parameters. For example the cocoon plugin was ment to unpack and write some configuration files in the WAR, configuration files which are not bindings to external servers, but settings for the internal servlets. In that case, it is a build problem, and not a configuration one. Also, the web.xml often contains directives which are "configuration" in the strict sense (like various init parameters), but also contains all the assembly informations of a web application, being unable to write plugins that can manipulate these file in the build phase is, IMMO, a problem. Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Stephane Nicoll wrote: > Yes, I've seen this thread as well. Sounds good to me even if we need > strong > use cases to create a new standard phase. > Basic use cases I've seen so far, applied to the WAR problem : - Cocoon team developed a plugin that deploys its blocks inside a war. This way, the user only have to specify which blocks their application depend on, and then the plugin will take them, unpack some certain files from a standard block jar structure inside some folders in the war, and do some other stuff on the web.xml and similar files. Right now this plugin has been developed as extending the AbstractWarMojo. Unfortunately this worked fine up to a certain version, but now fails with an NPE cause of what's written here http://www.mail-archive.com/dev@maven.apache.org/msg60770.html and here http://issues.apache.org/jira/browse/COCOON-1961 . - I've developed a plugin that applies XML patches to mostly every target directory structure, but if not subclassing the war mojo (and having the errors), or using other techniques (like running war exploded and then using the assembly plugin etc..), or using my patch (http://jira.codehaus.org/browse/MWAR-86 ) I have no way to see it work on a war directory structure before it gets packed. - For a project I'm doing and that I'll post on apache labs ASAP, I developed a plugin that taken a certain source folder structure creates a working cocoon application, generating sitemaps etc.. Same as above, no way to have it work to build a WAR out of it. - A friend of mine needed to run a legacy ant task on some files before packing the WAR, he wanted to use antrun but again... He ended up using war exploded and then appending to it's ant run a task to build the war. Adding a phase is, IMHHHO, not a lightweight change. Also, adding a "pre-package" phase sounds a bit like going back to maven1 pregoals, but a way to work between the prepare and the package phase of a packaging mojo is absolutely needed. Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Mark Hobson wrote: > This sounds similar to my requirement of splitting the package phase > into pre-package and package. Pre-package would assemble the exploded > archive, whereas package would perform the archiving itself. This > would allow other mojos to contribute to the archive assembly phase as > you require. > > See http://www.mail-archive.com/dev@maven.apache.org/msg62286.html Absolutely. A pre-package would be the right hook to place the war exploded goal so that it explodes the war structure, overlays and so on, while on the package phase it will only package it. Then other plugins could simply hook to the pre-package phase if they need to work on the stuff that will end up in the war/jar/whatever else. So, a big non-binding +1 for your proposal :) Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Mark Struberg wrote: > --- Brett Porter <[EMAIL PROTECTED]> schrieb: > >> Isn't that what war:war does? >> > In theory (documentation) i would say yes: > >> This goal simply package the directory created by >> > war:webapp goal. > > But unfortunately (for what i see in the code) the > buildExplodedWebapp is not seperated, but called from > within the WarMojo, and it seems to me that the > changes done manually may be overwritten. > > I haven't tested this though, so it's only a guess and > you should give this a try. > Yep, exactly. I opened the issue http://jira.codehaus.org/browse/MWAR-86, attached a patch, and commented a typical use case (a plugin that patches some files in the war, before "warring" it :) ). With the patch there is a snippet of how successfully managed to obtain create war structure -> work on it -> package the war file. Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Michael Horwitz wrote: > Hi Simone, > > You could try the following: > > 1) Run the war:inplace goal. > 2) Do the work on the exploded file. > 3) Run the normal war goal. > > There is a danger that step 3 will undo some of the changes you have > made - > it largely depends on what they are. Yep, that's it, it redoes some parts of it :) Wasn't there a war:something that only does the "zip the war" part? Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Manipulating the WAR directory before the WAR file gets built
Hi all, I've developed a couple of plugin (one performs XML patches, the other builds a certain site structure). They both should work on the WAR directory structure, but before the WAR file is currently built. Apart from my specific needs, it could be quite common to need to perform some tasks (with an antrun for example) on the WAR directory structure before zipping it in the WAR file. Is there a way to hook these plugins (or any plugins) in between of the WAR plugin? In case, could it be a good idea to split the WAR plugin in two different goals so that it's possible to prepare the WAR directory structure and zip it in two different phases? Another option could be to use the WAR plugin to produce the directory structure (copying all the dependencies jars in place, doing war overlay etc..) and then use the assembly plugin (or antrun with a jar task :) ) to produce the final WAR file. Is this possible? Thanks, Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
