Re: maven 2.0.7 reorders dependencies during build causing compilation failures
did you ever think that something is seriously wrong if the classpath ordering causes your build to fail? That could mean that sometime somewher someone will deploy your application and use a different order for the jars and it just won't run and the poor developer/ops person will have no idea... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
working around eclipse artifacts in repo version problems: Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0)
How do I work around this type of problem? --- CONSOLE LOG --- [INFO] Failed to resolve artifact. Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0) org.eclipse.equinox:app:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2) --- CONSOLE LOG --- Unfortunately the output doesn't specify which jar caused the OverConstrainedVersionException. Can I just hard code the dependency to the value I want once I find the culprit? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven 2.0.7 reorders dependencies during build causing compilation failures
Yes, I have and I don't see any problem. It is impossible to enforce every artifact in the transitive closure depends on same version of an artifact. Different artifacts evolve at different pace, while some may have a dependency on lower versions, some may require higher versions. It's not just about different versions of same artifact, sometimes different artifacts may have same classes in them and you may like to use classes from a particular artifact because that contains the correct version of classes you are looking for. More over, we (in GlassFish project) use OSGi, so when someone takes our artifact, they can always inspect all its dependencies and ensure they are met in their environment. If they don't ensure, they will get a nice message that will tell them that desired version of a package is not available. I hope you are not defending the unpredictable behavior of maven version 2.0.9. Michael McCallum wrote: did you ever think that something is seriously wrong if the classpath ordering causes your build to fail? That could mean that sometime somewher someone will deploy your application and use a different order for the jars and it just won't run and the poor developer/ops person will have no idea... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven 2.0.7 reorders dependencies during build causing compilation failures
Michael is expressing the bane of every developer no jar in classpath wrong version of jar in classpath if you can forward any details as to the web-application-server (WebLogic/JBoss/Webspeher) you are implementing with so we can get this corner-case figured out.. thanks, Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. From: [EMAIL PROTECTED] To: users@maven.apache.org Subject: Re: maven 2.0.7 reorders dependencies during build causing compilation failures Date: Sun, 19 Oct 2008 22:27:39 +1300 did you ever think that something is seriously wrong if the classpath ordering causes your build to fail? That could mean that sometime somewher someone will deploy your application and use a different order for the jars and it just won't run and the poor developer/ops person will have no idea... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ When your life is on the go—take your life with you. http://clk.atdmt.com/MRT/go/115298558/direct/01/
Re: working around eclipse artifacts in repo version problems: Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0)
you could change your range to be [1.0.0-!,2.0.0) the range you have specified starts with a version without a qualifier. qualified versions are before versions without a qualifier in Maven version ranges... so 1.0.0-v20070606 1.0.0 and therefore outside the range you have specified. The issue with including qualifiers is that now -SNAPSHOT builds can be included in the range. The other option is to exclude all the transitive dependencies and add back in the version you want 2008/10/19 Barrie Treloar [EMAIL PROTECTED] How do I work around this type of problem? --- CONSOLE LOG --- [INFO] Failed to resolve artifact. Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0) org.eclipse.equinox:app:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2) --- CONSOLE LOG --- Unfortunately the output doesn't specify which jar caused the OverConstrainedVersionException. Can I just hard code the dependency to the value I want once I find the culprit? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple executions of goals under generate-sources: How to avoid?
Lacking any other solution I went ahead and incorporated an internal Maven property that gets set at the end of the first code generation in the lifecycle. That way subsequent checks of the property provide an indication to skip code generation. This seems kind of kludgy but it works stug23 wrote: As a clarification, the execution that I am trying to avoid is the second execution of a code generator mojo that is bound to generate-sources phase. The second execution results from uses the maven-sources-plugin which states: Invokes the execution of the lifecycle phase generate-sources prior to executing itself. The information above is from the following reference: http://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html So my question is: Is there a way to still produce a sources jar using the maven-source-plugin without invoking execution of the generate-sources phase? It doesn't make sense to me that this invocation cannot be switched off since the code generation has already taken place and it's not very efficient to perform code generation all over again in a subsequent lifecycle phase. Perhaps there are cases where this is needed, but mine is not one of them, so I am hoping that someone can help me to disable this feature of the maven-source-plugin. TIA stug23 wrote: I am working on a code generator plugin that ends up being executed multiple times when in fact I only want it to execute once in the generate-sources phase. According to this posting http://www.mail-archive.com/users@maven.apache.org/msg78484.html this is an expected behavior. How do I avoid multiple executions of my code generator which needs to run in the generate-sources phase? TIA -- View this message in context: http://www.nabble.com/Multiple-executions-of-goals-under-generate-sources%3A-How-to-avoid--tp20038097p20057662.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]
Re: Is it possible to use maven to remote deploy a war file?
Great, thanks. That's nice to hear. Wendy Smoak wrote: On Sat, Oct 18, 2008 at 9:30 PM, Rusty Wright [EMAIL PROTECTED] wrote: Does anyone know if Cargo works with Tomcat 6? I can't find any mention of it on the Cargo web site. I believe so... according to JIRA support was added in February, and there have been some 1.0 alpha releases since then. http://jira.codehaus.org/browse/CARGO-563 (And rumor has it, before that it worked fine if you just used the tomcat5 instructions and pointed it at tomcat6.) Please ask on the Cargo user list if you're having trouble, you can find subscription info here: http://cargo.codehaus.org/Mailing+Lists - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing an artifacts classpath from a mojo?
Hi Jason!
Thanks for spotting the jetty plugin.
Jetty is now using an own classloader, but I looked at old versions and managed
to get classworlds working the way I need it.
There are a few hacks in the source, so maybe someone has a tip for making this
code prettier.
LieGrue,
strub
PS: the full code of the new openjpa-maven-plugin version can be found here:
git-clone http://ns1.backwork.net/git/openjpa-maven-plugin.git
PPS: thanks to Rahul for providing the first release of the openjpa plugin and
doing some additional reviews now.
/**
* This will prepare the current ClassLoader and add all jars and local
* classpaths (e.g. target/classes) needed by the OpenJPA task.
*
* @throws MojoExecutionException
*/
protected void extendRealmClasspath()
throws MojoExecutionException
{
ClassWorld world = new ClassWorld();
ClassRealm jpaRealm;
try
{
jpaRealm = world.newRealm( maven.plugin.openjpa
,
Thread.currentThread().getContextClassLoader() );
}
catch ( DuplicateRealmException e )
{
throw new MojoExecutionException( problem while creating new
ClassRealm, e );
}
Iterator itor = classpathElements.iterator();
while (itor.hasNext())
{
File pathelem = new File( (String) itor.next() );
getLog().debug( adding classpathElement + pathelem.getPath() );
try
{
// we need to use 3 slashes to prevent windoof from
interpreting 'file://D:/path' as server 'D'
// we also have to add a trailing slash after directory paths
URL url = new URL(file:/// + pathelem.getPath() + (
pathelem.isDirectory() ? / : ) );
jpaRealm.addConstituent( url );
}
catch ( MalformedURLException e )
{
throw new MojoExecutionException( error in adding the
classpath + pathelem, e );
}
}
// set the new ClassLoader as default for this Thread
Thread.currentThread().setContextClassLoader( jpaRealm.getClassLoader()
);
}
--- Jason van Zyl [EMAIL PROTECTED] schrieb am Mo, 13.10.2008:
Von: Jason van Zyl [EMAIL PROTECTED]
Betreff: Re: Accessing an artifacts classpath from a mojo?
An: Maven Users List users@maven.apache.org
Datum: Montag, 13. Oktober 2008, 18:28
Look at the Jetty plugin, Jan has done most of the work
there and I'm
sure you can lift it all.
On 13-Oct-08, at 8:23 AM, Mark Struberg wrote:
Hi!
I currently face a very similar problem: I'd like
to check for a
resource target/classes/META-INF/persistence.xml from
my plugin via
the plugins classloader (need the JDBC config from
there).
I'm currently messing around with Classworlds, but
haven't succeed
so far.
It would be a great if you can point us to a plugin
which has
implemented such a mechanism already. I'd hate to
call java via the
CommandLine for this :(
txs and LieGrue,
strub
--- Brett Porter [EMAIL PROTECTED]
schrieb am Mo, 13.10.2008:
Von: Brett Porter [EMAIL PROTECTED]
Betreff: Re: Accessing an artifacts classpath from
a mojo?
An: Maven Users List
users@maven.apache.org
Datum: Montag, 13. Oktober 2008, 12:45
How do you need to use it? It can be quite simple
to create
a
classloader for this, but it depends on how
it'll be
used.
Cheers,
Brett
On 13/10/2008, at 9:40 PM, Mark Derricutt wrote:
Hi all,
I have a maven plugin I'm working on and I
want to
include the
classpath
(main, test, others...) of the artifact
calling the
plugin - am I
going to
have to spawn/fork a new java process and
include them
on the
classpath
somehow, or is their some mojo-magic that
takes care
of this?
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
--
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]
__
Do You Yahoo!?
Sie sind
Re: working around eclipse artifacts in repo version problems: Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0)
On Mon, Oct 20, 2008 at 12:47 AM, Stephen Connolly [EMAIL PROTECTED] wrote: you could change your range to be [1.0.0-!,2.0.0) the range you have specified starts with a version without a qualifier. qualified versions are before versions without a qualifier in Maven version ranges... so 1.0.0-v20070606 1.0.0 and therefore outside the range you have specified. The issue with including qualifiers is that now -SNAPSHOT builds can be included in the range. Yeah, its a problem with the Maven - Eclipse version transformation. The version ranges of the org.eclipse.* jars in the maven central repo are unfortunately defined this way. The other option is to exclude all the transitive dependencies and add back in the version you want This is what I have done. I was wondering if there were alternatives though as this is a painful process :) I think I will also look at the code and make changes so that it informs what in the process caused the over constraining. At the moment, I can't tell, that information is not available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Select classes to Javadoc
How do I get the javadoc plugin to do only certain classes? The Ant javadoc task does it by letting you pass in a fileset. I can't find the equivalent in Maven. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Select classes to Javadoc
take a look at maven-javadoc-plugin http://maven.apache.org/plugins/maven-javadoc-plugin/ Here is an example plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId configuration links linkhttp://java.sun.com/j2ee/1.4.2/docs/api/link and this mechanism for configuring offline links if http://java.sun.com/j2se/1.4.2/docs/api unreachable try /opt/java-apidoc/j2sdk1.4.1/docs/api/ maven.javadoc.offlineLinks= \ http://java.sun.com/j2se/1.4.2/docs/api/#/opt/java-apidoc/j2sdk1.4.1/docs/api/ HTH/ Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. To: users@maven.apache.org From: [EMAIL PROTECTED] Subject: Select classes to Javadoc Date: Sun, 19 Oct 2008 16:38:49 -0500 How do I get the javadoc plugin to do only certain classes? The Ant javadoc task does it by letting you pass in a fileset. I can't find the equivalent in Maven. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ You live life beyond your PC. So now Windows goes beyond your PC. http://clk.atdmt.com/MRT/go/115298556/direct/01/
RE: How to silence Dependency plugin?
The dependency plugin plays no part in the default lifecycle, it's a utility player like assembly that lets you copy, unpack and analyze things. Those messages are probably coming from the war plugin itself. -Original Message- From: David C. Hicks [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 3:09 PM To: Maven Users Subject: How to silence Dependency plugin? I'm getting a bunch of messages from the Dependency plugin (i think) during the [war:war] phase of my build. They are of the form: [INFO] Dependency [Dependency ... ] has changed (was Dependency ...). The weird thing is that the before and after dependencies are actually identical. So, I fail to see what changed. Is there any way to shut this thing up? It's just a bunch of clutter, as far as I can tell. I tried adding the dependency plugin with the silent option... plugin artifactIdmaven-dependency-plugin/artifactId configuration silenttrue/silent /configuration /plugin This had no effect. Any help? Thanks, Dave - 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: How to silence Dependency plugin?
Thanks for the feedback, Brian. I'll check the war plugin and see if I can find something in its options. Dave Brian E. Fox wrote: The dependency plugin plays no part in the default lifecycle, it's a utility player like assembly that lets you copy, unpack and analyze things. Those messages are probably coming from the war plugin itself. -Original Message- From: David C. Hicks [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 3:09 PM To: Maven Users Subject: How to silence Dependency plugin? I'm getting a bunch of messages from the Dependency plugin (i think) during the [war:war] phase of my build. They are of the form: [INFO] Dependency [Dependency ... ] has changed (was Dependency ...). The weird thing is that the before and after dependencies are actually identical. So, I fail to see what changed. Is there any way to shut this thing up? It's just a bunch of clutter, as far as I can tell. I tried adding the dependency plugin with the silent option... plugin artifactIdmaven-dependency-plugin/artifactId configuration silenttrue/silent /configuration /plugin This had no effect. Any help? Thanks, Dave - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can use Maven SCM plugin API to Move some versiond SVN File from one folde to another?
I have some project have bad structure and I want to modify it to SVN fold structure, If do it manually, i will be time consuming and easily make mistakes. I want to ask ,can Maven SCM API Help me do this kind of things?
