Re: Force snapshots to update always?

[Simon Kitching]

 Jon Anning <[EMAIL PROTECTED]> schrieb:
> Is there a way of setting the behaviour of the -U (--update-snapshots)
> switch to be the default when running mvn? Or do I have to set the
> updatePolicy element to be true for each given repository?

export MAVEN_OPTS="-U"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: damage image files

[Simon Kitching]

 John Coleman <[EMAIL PROTECTED]> schrieb:
> Hi,
> 
> We are finding that our Maven build is damaging jpg and gif files during
> the copy of resources into the target area. Is there something in the
> config to tell it not to mess with binary resources? Is this an issue
> with filters perhaps, or of locating image resources under the java
> directory?

You mean just copying from a dir under src to target?

Maven will not modify anything unless you explicitly have resource-filtering 
turned on. Maybe one of the parent poms has filtering enabled?

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Enforcer Plugin 1.0 release and requirePluginVersions rule

[Simon Kitching]

Yep, that does seem to break the convention that Wendy described. 
enforcer 1.0-alpha-3 is the latest release, 10-JUL-2007.
But the site is 1.0-SNAPSHOT 17-JAN-2008.

PS: sigh, more top-posting in reply to a bottom-post. Why do people do this?

 Ben Lidgey <[EMAIL PROTECTED]> schrieb:
> 
> At the moment I am looking at the Maven Enforcer Plugin, as I am working on 
> some custom rules to support our dev process, and noticed the docs are for 
> 1.0-SNAPSHOT which doesn't seem to be in the repository. I've not looked 
> through the other plugins to see if they are the same.
> 
> Ben
> 
> > -Original Message-
> > From: Wendy Smoak [mailto:[EMAIL PROTECTED]
> > Sent: 11 February 2008 17:20
> > To: Maven Users List
> > Subject: Re: Enforcer Plugin 1.0 release and
> > requirePluginVersions rule
> >
> > On Feb 11, 2008 7:45 AM, Ian Springer <[EMAIL PROTECTED]> wrote:
> >
> > > +1 for not posting SNAPSHOT plugin docs on the website. The docs
> > > +should
> > > correspond to the latest released version.
> >
> > That's the model we now follow, though there may still be
> > some leftover snapshot sites if the plugin hasn't been
> > released in a long time.
> >
> > And there are some exceptions, such as
> > http://maven.apache.org/plugins/maven-archetype-plugin/ .
> > (In this case I published snapshot docs because they were
> > committed _after_ the recent 2.0-alpha-1 release.  I don't
> > believe there were any code changes yet, so these docs should
> > stay until 2.0-alpha-2 is released.)
> >
> > Ben, are there some in particular that caused problems for you?
> >

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Weird behaviour with dependency range

[Simon Kitching]

Yes, the NPE occurs when no version is found, rather like the other bugreports.

But the scary part about this is something different. It is that it appears 
that the version specification is silently ignored. In the example below, there 
is no version to "fall back to" so the NPE occurs. But if there is a version to 
"fall back to", eg a dependencyManagement entry in the parent pom then no NPE 
occurs, and the version specified in the pom is just silently ignored.

This seems to be a different issue than the ones about the NPE.

Unless someone can tell me this is user error, I'll file a separate issue for 
this.

Regards,
Simon

 "Brian E. Fox" <[EMAIL PROTECTED]> schrieb:
> Looks like the same npe as MNG-3372 and MNG-3351
> 
> -Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED] 
> Sent: Monday, February 11, 2008 7:51 AM
> To: users@maven.apache.org
> Subject: Weird behaviour with dependency range
> 
> Hi,
> 
> I've run across something very odd with dependency ranges.
> 
> Maven version: 2.0.8
> java: 1.6
> 
> If I put this in my pom
> 
>   commons-logging
>   commons-logging
>   [1.0.9]
> 
> then run dependency:tree I get an error:
> 
> 
> Couldn't find a version in [1.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.1, 1.1.1, 
> 1.1.1-SNAPSHOT] to match range [1.0.9,1.0.9]
> 
> 
> So far so good. But if I change this to 1.0.1, I get this:
> 
> java.lang.NullPointerException: version was null for 
> commons-logging:commons-logging
> at 
> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
> at 
> org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)
> 
> 
> Any idea what is going on here?
> 
> The initial problem I struck was even subtler; a parent pom was using 
> dependencyManagement to set the version. I tried to override in the child pom 
> but dependency:tree was still reporting the version defined in the parent.
> 
> It looks like [version] fails correctly when the version does not exist, but 
> is silently ignored when the version actually exists.
> 
> The same thing happens for [1.0,1.1.1) and similar ranges.
> 
> Regards,
> Simon
> 
> -
> 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]

Weird behaviour with dependency range

[Simon Kitching]

Hi,

I've run across something very odd with dependency ranges.

Maven version: 2.0.8
java: 1.6

If I put this in my pom

  commons-logging
  commons-logging
  [1.0.9]

then run dependency:tree I get an error:


Couldn't find a version in [1.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.1, 1.1.1, 
1.1.1-SNAPSHOT] to match range [1.0.9,1.0.9]


So far so good. But if I change this to 1.0.1, I get this:

java.lang.NullPointerException: version was null for 
commons-logging:commons-logging
at 
org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
at 
org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)


Any idea what is going on here?

The initial problem I struck was even subtler; a parent pom was using 
dependencyManagement to set the version. I tried to override in the child pom 
but dependency:tree was still reporting the version defined in the parent.

It looks like [version] fails correctly when the version does not exist, but is 
silently ignored when the version actually exists.

The same thing happens for [1.0,1.1.1) and similar ranges.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven Concepts

[Simon Kitching]

 Stephen Connolly <[EMAIL PROTECTED]> schrieb:
> Redeploying a non-SNAPSHOT version is a _bad thing_ as Maven will not
> re-download it.

Absolutely. Never overwrite an existing deployed file except when it has 
SNAPSHOT in the version.

Builds should be repeatable, ie you should be able to compile something today, 
then compile it again next week and get the same result. This means that stuff 
deployed to a repository should never change.

The only exception is SNAPSHOT versions; when a project depends on one of 
these, then it is explicitly acknowledging that repeatable builds are not 
possible. 

One of the things the release plugin does is check that there are no SNAPSHOT 
dependencies anywere; if there are then it refuses to continue with the release 
process as the release is not repeatable. Of course using the release plugin is 
not mandatory, but that particular check is a very good idea.

And because Maven assumes people never overwrite non-snapshot files, it never 
bothers to check for newer ones. Only with SNAPSHOTs does maven look for newer 
versions, on an "every time", "daily" or "weekly" basis as configured.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attaching javadoc to a non-maven artefact

[Simon Kitching]

 Richard Chamberlain <[EMAIL PROTECTED]> schrieb:
> Hey all,
> 
> I've got a non maven artefact that i've added to my company repository
> with mvn deploy:deploy-file. However i also have the javadoc and would
> like to add it to the repo.
> 
> mvn deploy:deploy-file seems to only handle one file, so i'm at a loss
> as to how to get the javadoc in the repo.

Just copy it there, using scp or whatever works for your system. 

Using deploy-file is important for the binary code jar, in order to create the 
right meta-data files. But AFAIK there is no additional meta-data needed for 
associated files like javadoc or source.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javax.mail and javax.activation in Java 6

[Simon Kitching]

 Simon Kitching <[EMAIL PROTECTED]> schrieb:
>  Doug Donohoe <[EMAIL PROTECTED]> schrieb:
> > Hi Maven Community:
> > 
> > I have added this dependency in my POM:
> > 
> >   
> > javax.mail
> > mail
> > 1.4.1
> >   
> > 
> > Which is retrieved from java.net using this POM definition:
> > 
> >   
> > 
> >   java.net
> >   http://download.java.net/maven/1
> >   legacy
> > 
> >   
> > 
> > The POM for javax.mail declares a dependency on the Java activation 
> > framework.  However, I am using Java 6 (1.6.0_02), which already 
> > includes the activation framework.
> > 
> > My question:  Is there a way in maven to conditionally define a 
> > dependency based on the JDK you are using?
> > 
> > If there is, what is the best way for me to use such a mechanism.  
> > Ideally, the POM at java.net would be updated, but assuming I can't 
> > figure out how to get them to update that, how do I override there POM?
> > 
> 
> Try defining a profile called "java6" in your pom. Set its activation section 
> so it only activates for java1.6. Then in the profile define that problem 
> dependency with scope=provided.
> 
> I think that will do the job. Dependencies declared directly in a pom always 
> override those pulled in transiently. That definitely occurs for 
> version-numbers, and I *think* it works for scope too.

Umm..except that what you probably are asking for is a way to *exclude* the 
dependency rather than just have scope=provided.

Dependencies can be excluded easily enough:
 
   javax.mail
   mail
   1.4.1
   
 ... (see documentation) ...
   
  

I don't know of any way of declaring "global" exclusions (eg from within a 
profile); in fact I'm pretty sure that is a feature request already filed for 
Maven.

So I think you would have to put this complete block above in the java6 profile 
section.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javax.mail and javax.activation in Java 6

[Simon Kitching]

 Doug Donohoe <[EMAIL PROTECTED]> schrieb:
> Hi Maven Community:
> 
> I have added this dependency in my POM:
> 
>   
> javax.mail
> mail
> 1.4.1
>   
> 
> Which is retrieved from java.net using this POM definition:
> 
>   
> 
>   java.net
>   http://download.java.net/maven/1
>   legacy
> 
>   
> 
> The POM for javax.mail declares a dependency on the Java activation 
> framework.  However, I am using Java 6 (1.6.0_02), which already 
> includes the activation framework.
> 
> My question:  Is there a way in maven to conditionally define a 
> dependency based on the JDK you are using?
> 
> If there is, what is the best way for me to use such a mechanism.  
> Ideally, the POM at java.net would be updated, but assuming I can't 
> figure out how to get them to update that, how do I override there POM?
> 

Try defining a profile called "java6" in your pom. Set its activation section 
so it only activates for java1.6. Then in the profile define that problem 
dependency with scope=provided.

I think that will do the job. Dependencies declared directly in a pom always 
override those pulled in transiently. That definitely occurs for 
version-numbers, and I *think* it works for scope too.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: howto configure svn access with maven2 using ssh connection

[Simon Kitching]

 Ulrich Metzger <[EMAIL PROTECTED]> schrieb:
> Hi list,
> i tryed to configure the scm settings in a maven 2 pom.xml using ssh to
> access the remote svn repository.
> But i could not find any example or documentation how to manage this.
> Does anybody know if this is possible and if yes, how to set up this kind of
> repository access, when a username and password is required for ssh login on
> the remote machine.
> I would be interested in a solution which works with Windows and Linux
> client systems.

I have this in ~/.m2/settings.xml:


  

  server1
  user1
  pwd1



  server2
  user2
  pwd2
  /home/user2/.ssh/somekey

  


where the ids match the id properties of the repository definitions in the 
pom.xml file.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problematic Parent tag.

[Simon Kitching]

Two choices:

(1) Run "mvn -N deploy" in parent dir. This will deploy just the parent pom, 
without recursing down into modules.

(2) Make the parent pom into its own project. 
The directory structure would then be
  rootdir
parentpom-module
a-module
b-module
c-module
 
In rootdir, you can choose to put a trivial pom if you want, which just 
contains a bunch of  tags and nothing else. This allows commands to be 
run across all modules. Or have nothing there.

The pom in the rootdir (if one exists) is *not* what a-module, b-module etc 
reference as their parent pom. They reference the pom in parentpom-module.

Maven doesn't care where the parent pom is; it can be hosted by a different 
company in a different country if you want. So having it in a directory which 
is not ".." is no problem.

In this case, to release the parent pom, obviously just run "mvn deploy" in the 
parentpom-module directory.

Regards, Simon

 amit kumar <[EMAIL PROTECTED]> schrieb:
> But under the parent of a.jar there are other projects as well which are
> owned by different developers. The scenario is like:
>*Parent Project
> a.jar*(developer1)* c.war*(developer2)*   d.jar*(developer3)
> 
> All the three developers are responsible for deploying artifacts. So how to
> ensure the Parent Project's pom gets gets installed/deployed in the Intranet
> repository, and who should be installing that? Because every developer does
> like  *C:\Parent Project\a>mvn deploy. *This doesn't result in the
> deployment of parent project's pom.
> 
> 
> Thanks and Regards,
> Amit
> 
> 
> 
> On Feb 5, 2008 7:20 PM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> 
> > amit kumar wrote:
> >
> > > Say I have deployed *a.jar* ( whose pom has a parent tag, since it is a
> > > sub-module of the whole project as such), and *b.jar* has *a.jar* in its
> > > dependency.
> > > Now when I run a maven goal I see the error in which it tells that maven
> > was
> > > not able to find the the parent pom ( it sees the parent tag in the *
> > a.jar's
> > > * pom and tries to look for it, which obviously it doesn't find.) The
> > parent
> > > to *a.jar* is just a logical project with packaging type as pom.
> > >
> > > Could someone please help out. This problem kind of brought everything
> > in
> > > release automation on the knees.
> >
> > You need to install and/or deploy and release the parent pom as well as
> > your a.jar and b.jar, and you need to install it first.
> >
> > If you do a deploy or an install from the parent parent project, maven
> > figures out how to do this on its own.
> >
> > Parent pom files go into both local and remote repositories, just like
> > the pom files belonging to the jars, and follow the same rules.
> >
> > Regards,
> > Graham
> > --
> >


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: parent inheritence (site plugin)

[Simon Kitching]

 "Ritz schrieb:
> Hi User Group,
> 
> I have a project with some submodules and generating the site of the whole 
> project through executing of the parents level.
> I want to display the parent in the left navigation bar.
> I found the only way is to do this is the element " inherit="bottom"/>" in the parent which is inheritanced through the childs.
> This works only for the goal "site:stage" but not for my normal goal "site 
> site:deploy".
> I don't want to stage the site. My goal ("site site:deploy") works fine 
> unless the parent link in the sidebar.
> 
> I tried out with some versions (last one: 2.0-beta-7-20071130.000106-1) but 
> there is no difference.
> 
> Is there another way of creating a link in the childs site to the parent site?
> Why is "site:stage" the only goal which works for me?

Are you sure it is the deploy that is the problem?

There is currently a bug in the maven-site-plugin that causes a module to fail 
to find its site.xml file if mvn was run in a parent directory.

So if you have a directory tree with a pom that uses  tags to point to 
modules in subdirectories, "mvn site-deploy" will NOT work when run in the 
parent dir, but will work when run in each child directory.

Regards,
Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to debug transitive dependencies

[Simon Kitching]

In the recently-released version of the dependency plugin there is now the 
possibility to run
   mvn dependency:tree

This should show you why those jars are being pulled in.

You will need maven 2.0.8 for dependency:tree to run correctly.

Regards, Simon

 Arash Bizhan zadeh <[EMAIL PROTECTED]> schrieb:
> I got the problem. Strangely myfaces and portlet APIs were ended up in my
> war file. The problem was that  I mentioned commons-chaining in pom as a
> dependency, and it is depend on those jar files; I removed the explicit
> dependency to it and strangely, now I have it in my war file but not the
> dependencies to myfaces and ...!
> Though I could not completely figure out how transitive dependency works and
> why this happened?!
> 
> On Feb 4, 2008 6:19 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> 
> > try mvn -npu
> > -npu,--no-plugin-updates  Suppress upToDate check for any relevant
> > registered plugins
> >
> > which jars are being included that are not supposed to be included?
> >
> > M-
> > - Original Message -
> > From: "Michael McCallum" <[EMAIL PROTECTED]>
> > To: "Maven Users List" 
> > Sent: Monday, February 04, 2008 6:11 PM
> > Subject: Re: How to debug transitive dependencies
> >
> >
> > > On Tue, 05 Feb 2008 10:03:56 Arash Bizhan zadeh wrote:
> > > > I am getting some strange unrelated jar files inside my war package.
> > Could
> > > > somebody tell me how can I debug the transitive resolution process and
> > > > eliminate unrelated jar files?
> > > >
> > > > Thanks
> > > > Arash
> > >
> > > mvn dependency:resolve -X
> > >
> > > --
> > > Michael McCallum
> > > Enterprise Engineer
> > > mailto:[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]
> >
> >
> 
> 
> -- 
> You can not depend on your eyes when your imagination is out of focus.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: bootstrapping repos

[Simon Kitching]

 Lorenzo Bigagli <[EMAIL PROTECTED]> schrieb:
> I put all the  in a parent pom,  but now of course all 
> children poms look for their father in the central (and fail)...
> Am I doomed to bootstrap the  info in the settings, too?

Yep. At least the one repository that contains the parent is needed (assuming 
child modules cannot locate the parent on the local disk via the relativePath 
attribute).

Once the parent pom can be found, then the other repos it defines become 
available.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ignoring test dependencies when you run maven with maven.test.skip=true

[Simon Kitching]

 Simon Kitching <[EMAIL PROTECTED]> schrieb:
> Tests can take a long time to run, so it's useful to sometimes skip that. But 
> compiling them is not normally something that people want to skip; checking 
> in code that breaks the compilation of tests should almost always be a build 
> failure.
> 
> If you read the surefire documentation, it explicitly says that *running* of 
> the tests is skipped, not compiling.
> 
> And anyway, the surefire plugin has the responsibility for running the tests, 
> but it is the maven-compiler-plugin that has the responsibility for compiling 
> them.

 nicolas de loof <[EMAIL PROTECTED]> schrieb:
> Build your project with maven.test.skip.exec=true
> 
> This will build the required test-jar dependencies but skip test execution.

Thanks for pointing that out Nicolas. All this time, I had not realised that 
maven.test.skip was also skipping compilation of test classes!

The primary documentation on the surefire plugin is not at all clear on this 
issue, BTW. But after drilling down into the plugin-documentation under the 
project reports, it does indeed say so.

And in compiler plugin, after drilling down into project-reports | 
plugin-documenation it can be seen that this plugin uses the same flag to 
disable compilation of test classes - interesting.

BTW, just to clarify: I misunderstood the original email in this thread: the 
original poster *wanted* to compile the unit tests but not run them, and was 
surprised when maven.test.skip also prevented compilation. As Nicolas points 
out, maven.test.skip.exec is the right thing to use in that case.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ignoring test dependencies when you run maven with maven.test.skip=true

[Simon Kitching]

 Rohnny Moland <[EMAIL PROTECTED]> schrieb:
> Hello,
> 
> I was reading this:
> 
> .
> 
> It works fine if I build my project and run the tests, but what if I
> want to just build my project and skip the tests? I get a dependency
> resolution error then, because my test dependency cannot be found.
> 
> I know 2 possible solutions:
> 1) Create a profile and include my test dependency in it. This is
> misuse of a profile in my opinion.
> 2) Deploy the test dependency in a local repository and only depend on
> it as a binary.
> 
> I dont really understand why the reactor does not ignore dependencies
> with scope=test, when you run maven with the skip test option set to
> true. Isnt this how it should be?

No, it's working as designed.

Tests can take a long time to run, so it's useful to sometimes skip that. But 
compiling them is not normally something that people want to skip; checking in 
code that breaks the compilation of tests should almost always be a build 
failure.

If you read the surefire documentation, it explicitly says that *running* of 
the tests is skipped, not compiling.

And anyway, the surefire plugin has the responsibility for running the tests, 
but it is the maven-compiler-plugin that has the responsibility for compiling 
them.

You can disable compilation of tests by excluding classes in the 
maven-compiler-plugin configuration, but I don't think that will block 
downloading of test dependencies. 

In your case, putting the test dependencies in a separate profile would seem to 
be the appropriate solution. It doesn't seem like an abuse of profiles to me; 
you have two alternative configurations one of which has some dependencies that 
the other does not. That seems a quite reasonable use of a profile.

Regards,
Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven renaming jar files

[Simon Kitching]

I've certainly done something similar in the past. To reduce network traffic, 
and to better control what libs are used, it is nice to have a repository on a 
local server hosting the jars you need.

It is very tempting to just take the set of jars you have always been using (in 
an existing ant-based build process or similar) and just upload them to that 
new repository. It is certainly easier than finding a maven repository proxy 
application, and setting that up.

I don't see a lot wrong with doing that - except that you do need to get the 
group ids right!

Of course long-term, having a proper repository manager installed locally 
appears to be the right solution. Some day I have to get that organised for my 
workplace...

Interesting to see that the war plugin does detect filename clashes; as 
discussed in another thread recently it appears that the dependency plugin does 
not...

Regards,
Simon

 Wayne Fay <[EMAIL PROTECTED]> schrieb:
> If you're using "mvn install" or "mvn deploy" to install/deploy common
> artifacts like commons-logging etc, then you're probably using Maven
> wrong.
> 
> What you've described is exactly what the problem was. You had added
> c-l as a particular G/A/V and then c-l was coming in as a transitive
> dep under a different G/A/V. Since the plugin detected a name
> collision, it expanded the name to include the group as well, to make
> it unique.
> 
> Why did you install/deploy commons-logging instead of simply adding a
> ? You're not the first person to report doing this, so I
> want to understand if there is a failure in the documentation
> somewhere or if new users are simply making poor assumptions about
> what Maven does.
> 
> Wayne
> 
> On 1/31/08, amit kumar <[EMAIL PROTECTED]> wrote:
> > I have overcome the problem. And guess know the reason for that,
> > actually at the time of creating the LAN maven repository, I have
> > installed common components under org.apache.commons groupId (
> > assuming the convention of groupId as package name ). So now when I
> > was including commons-logging as dependency in my pom.xml,
> > what I added to pom looked like
> >
> > org.apache.commons
> > commons-logging
> > 1.1
> >
> > But there was another dependency in my pom.xml which as
> > commons-logging as transitive dependency with same version, so what
> > was happening(probably) was that maven instead of overriding the jar
> > file was renaming it, may be because the jars were differently
> > identified as groupId+artifactId+version.
> > Still a little confused about my own explanation of the happenings :)
> >
> > Amit
> >
> > On Jan 30, 2008 9:51 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote:
> > > Looks weird.
> > > Do you use a released version ? or the current snapshot ?
> > >
> > > Could you load an issue in jira with a simple project which reproduce 
> > > this ?
> > >
> > > --
> > > Olivier
> > >
> > > 2008/1/30, amit kumar <[EMAIL PROTECTED]>:
> > >
> > > > Hi,.
> > > > When I am packaging a WAR project, I am seeing the following thing 
> > > > happening...
> > > >
> > > > [DEBUG] Processing: commons-logging-1.1.jar
> > > > [DEBUG] Duplicate found: commons-logging-1.1.jar
> > > > [DEBUG] Renamed to: commons-logging-commons-logging-1.1.jar
> > > >
> > > > Any idea why this happens and how to avoid this?
> > > > I am mentioning commons-logging-1.1 as my dependency in the pom.xml,
> > > > and have suppressed the other versions of commons logging which were
> > > > getting packaged as transitive dependencies of project dependencies
> > > > using  tag in dependency taf. Same is happening with
> > > > commons-digester and other dependencies.
> > > >
> > > >
> > > > Regards,
> > > > Amit
> > > >
> > > > -
> > > > 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]
> >
> >
> 
> -
> 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: want to save in one folder all dependency jars?

[Simon Kitching]

 "Krastev schrieb:
> Hi all,
> please could you tell me is there a maven command which allows you to
> save in a predefined folder all POM dependency jars?
> say something like:
> mvn -xxx C:\temp

See the documentation for the dependency plugin:

  http://maven.apache.org/plugins/maven-dependency-plugin/

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven2 and artifact versions

[Simon Kitching]

 "Jörg Schaible" <[EMAIL PROTECTED]> schrieb:
> Simon Kitching wrote:
> 
> [snip]
> 
> > Personally, I prefer the second because it is clear to all
> > readers that yes a version *is* being specified for this
> > dependency. With the dependencyManagement approach, it isn't
> > clear unless you check the parent pom. However I appear to be
> > in the minority, with many people preferring dependencyManagement.
> 
> Because the dependencyManagement also define the version of the transitive 
> deps (at least it should since M206).

Good point. Using the $foo approach only works for direct 
dependencies; it cannot be used to influence the selected version for a 
transitive dependency.

However if you want dependencyManagement to apply to transient deps, you would 
really need to use [x.y] or [x.y,z.a] version numbers, right?

If a pom has a dependencyManagement declaration of 
  1.0
but some required lib declares a dependency on the same artifact using
   [1.2,1.4]
then what will happen?

I presume that version 1.2 will be used, ie the dependencyManagement 
declaration is ignored. If that is true, then it cannot actually be relied on 
unless dependencyManagement uses explicitly locked versions (or ranges).

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven2 and artifact versions

[Simon Kitching]

 Guillaume Lederrey <[EMAIL PROTECTED]> schrieb:
> On 31/01/2008, amidrunk <[EMAIL PROTECTED]> wrote:
> > Is there any good way to manage versions of dependencies in maven? In maven1
> > it was possible to define the version in a properties file in a root
> > project. Is there something similiar in maven2? Right now we define the
> > versions in settings.xml, but that is not a feasible long-term solution.
> 
> 
> Have a look at dependencyManagement :
> http://maven.apache.org/pom#Dependency_Management

Yep, using dependncyManagement in a parent pom will allow you to then have
> > 
> >com.mycompany
> >myArtifact
> > 

The alternative is to do this in a parent pom:

  1.1


That will allow you to have:
> > 
> >com.mycompany
> >myArtifact
> >${com.mycompany.version}
> > 

Personally, I prefer the second because it is clear to all readers that yes a 
version *is* being specified for this dependency. With the dependencyManagement 
approach, it isn't clear unless you check the parent pom. However I appear to 
be in the minority, with many people preferring dependencyManagement.

Regards, Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Conflicting Jar Names

[Simon Kitching]

This looks to me like a bug (or at least an oversight) in the dependency 
plugin. I presume this is what you are using to copy all the jars into a 
directory before building your "installer"?

Duplicate artifactIds are not normally a problem for maven; the classpath it 
builds for compiling, testing, etc will look like
  -classpath
$M2REPO/group1/artifact1/artifact1-1.0.jar;
$M2REPO/group2/artifact1/artifact1-1.0.jar
which is absolutely no problem.

The problem only comes when something like the dependency plugin tries to copy 
all the files into a single flat directory.

I think that the dependency plugin should check for duplicate artifactId values 
in the set of files it is extracting, and if one is found then use a "full" 
jarname, eg
  groupid-artifactid-version.jar
for the file it writes, instead of the "short" name.

However that's no use to you as a workaround :-(

Regards,
Simon

 Jeff MAURY <[EMAIL PROTECTED]> schrieb:
> Steve,
> 
> you can change the name of the JAR being generated through the finalName
> tag: it specifies the name of the file being generated. By default, it is
> equal to ${artifactId}-${version}.${packaging} so you may change it to:
> ${groupId}-${artifactId}-${version}.${packaging} for your purpose.
> 
> Jeff
> 
> 
> On Jan 29, 2008 7:04 PM, Lee Meador <[EMAIL PROTECTED]> wrote:
> 
> > 1 isn't going to work because of how Maven finds files in the repo by
> > tracing down the file system path based on the group id and then going
> > down
> > the path some more based on the artifact id and expecting the jar file to
> > have a matching name.
> >
> > The real solution is to change the artifactId, which you said would be
> > error
> > prone. It sounds like what you have is error prone already since your
> > build
> > process is having trouble telling jar files with the same name apart.
> >
> > Sorry for no good news. Maybe someone else know more about it than i do.
> >
> > -- Lee
> >
> > On Jan 29, 2008 10:45 AM, Steve Found <[EMAIL PROTECTED]> wrote:
> >
> > > Hi all,
> > >
> > > I have two  separate systems that I build using maven.
> > >
> > > One has groupId:com.volantis.synergetics artifactId:repository-api
> > > version:5.0-SNAPSHOT.  This system consists of around 50 artifacts.
> > >
> > > The second has groupId:com.volantis.mcs  artifactId:repository-api
> > > version:5.0-SNAPSHOT. This system consists of around 150 artifacts.
> > >
> > > When I come to build an installer, the jar files are all copied into a
> > > packaging directory, but as you can probably see, both jar files will be
> > > called repository-api-5.0-SNAPSHOT.jar. Consequently, the second jar
> > > will overwrite the first.
> > >
> > > Now I could go and change all the artifactId's for this, but given that
> > > there are many more than just 2 systems in the project this would be
> > > very time consuming and prone to error.
> > >
> > > What I want to do therefore is either :
> > >
> > > 1. Be able to set the name of the jar file when 'mvn install' installs
> > > the generated jar the repository so that the jar files do not conflict
> > > when the installer resolves it's dependancies. I tried setting the name
> > > of the generated jar from each subsystem pom, but this was lost when the
> > > jar was installed.
> > >
> > > 2. Be able to change the name of the jar when the dependancy is resolved
> > > but without adding each and every dependancy to the installer POM. For
> > > example... can I prepend volantis-synergetics- to every jar file that
> > > has a groupId of com.volantis.synergetics ? In the above example then I
> > > would get volantis-synergetics-repository-api.5.0-SNAPSHOT.jar and
> > > volantis-mcs-repository-api.5.0-SNAPSHOT.jar.
> > >
> > > Is there any way I can achieve these things through the install or
> > > dependancy plugins ?
> > >
> > > Regards,
> > >
> > >   Steve.
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > -- Lee Meador
> > Sent from gmail. My real email address is lee AT leemeador.com
> >
> 
> 
> 
> -- 
> La mélancolie c'est communiste
> Tout le monde y a droit de temps en temps
> La mélancolie n'est pas capitaliste
> C'est même gratuit pour les perdants
> La mélancolie c'est pacifiste
> On ne lui rentre jamais dedans
> La mélancolie oh tu sais ça existe
> Elle se prend même avec des gants
> La mélancolie c'est pour les syndicalistes
> Il faut juste sa carte de permanent
> 
> Miossec (2006)
> 
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Parent project version

[Simon Kitching]

Hi Mick,

I don't think there is any way to do what you are trying to do.

Having modules in a directory tree is just an optimisation; maven should be 
able to build any module when it is just checked out on its own.

In other words, the  tag is just an optimisation that works 
*when* modules happen to be checked out together, but a pom *must* work when 
the parent is only available via a lookup of the repository.

If a module is checked out on its own, and there is insufficient information to 
find the parent without relying on the  then that is an error.

So of course a version *must* be specified in the parent tag (otherwise there 
is no way to know which version to pull from the repository). And that version 
must *not* be defined in terms of data defined in the parent pom, otherwise an 
obvious problem occurs: the parent pom would be needed to determine which 
parent pom is needed.

Regards,
Simon

 Mick Knutson <[EMAIL PROTECTED]> schrieb:
> I can comment out the modules  just fine then, but the parent:
> 
> 
> org.delta.esp.dap.eep
> services
> 1.0.2
> ../pom.xml
> 
> 
> 
> 
> Still is complaining if I do not have the version.
> I also tried ${org.delta.esp.dap.eep.version} as the version but it could
> not find it.
> 
> 
> 
> 
> On Jan 29, 2008 12:11 PM, Erez Nahir <[EMAIL PROTECTED]> wrote:
> 
> > IMHO it should even be easier, just remove the  tag from the
> > child
> > poms.
> > It will inherit the version from the parent.
> >
> > Erez.
> >
> > On Jan 29, 2008 9:52 PM, Manos Batsis <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > I never actually managed to do that. IMHO that should be as easy as
> > >
> > > ${project.parent.version}
> > >
> > > Oh well :-)
> > >
> > > Cheers,
> > >
> > > Manos
> > >
> > > Mick Knutson wrote:
> > > > I am actually trying to use a property:
> > > >
> > > > 1.0.2
> > > >
> > > > Then use that property in my child pom's:
> > > >
> > > > ${org.delta.esp.dap.version}
> > > >
> > > > When I do an install and deploy it seems to work, but when I am doing
> > a
> > > > site-deploy, the parameter is not found and I get errors.
> > > >
> > > > Is there a better way?
> > > >
> > > >
> > > >
> > > > On Jan 29, 2008 10:23 AM, Arthur Rodrigues Stilben <
> > > > [EMAIL PROTECTED]> wrote:
> > > >
> > > >> Is there a way to use the version of a parent project in its
> > childrens
> > > >> projects?
> > > >>
> > > >> Arthur Rodrigues Stilben
> > > >>
> > > >> -
> > > >> 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,
> Mick Knutson
> 
> http://www.baselogic.com
> http://www.blincmagazine.com
> http://www.djmick.com
> http://www.myspace.com/mickknutson
> http://www.myspace.com/BLiNCMagazine
> http://tahoe.baselogic.com
> ---


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: how to detect version conflicts?

[Simon Kitching]

 [EMAIL PROTECTED] schrieb:
> Hi, 
> 
> I´ve read about dependencyManagement, versions, version ranges and so on.
> But still I have some questions:
> 
> Following example:
> 
> A1.0 references B1.0 
> A1.0 references C1.0
> B1.0 references C2.0
> 
> which version of C will be used (packed in a war for example) in this 
> scenario, if A is a module of type war, ear or zip ?
> how can I fail the build or trace at least a warning that there´s the same 
> artifact, but in different versions?

A version declaration like
  1.1
effectively says "I don't really care what version of this dependency is used, 
but I have a mild preference for version 1.1".

When building module A, if all references to a library use this form, then 
Maven will use the declaration "closest to" pom A to select the actual version 
used.

So in your example, if all the declarations are of the above form, then when 
compiling module A, C1.0 will be used because it is referenced directly from 
the pom for module A.

However the form "[x.y]" can be used to specify that only that version is 
acceptable. So if B declares its dependency on C as
  [2.0]
then I *believe* that when compiling A, C2.0 will be used (because A has used 
the form that says it doesn't really care).

If A declares
  [1.0]
but B declares
  [2.0]
then an error is reported and the build fails, because there is no version that 
can satisfy them both.

In general, version dependencies should be specified in the least-constrained 
form possible. Certainly *libraries* should avoid [x.y] type constraints if 
possible, as it makes it very difficult to combine that lib with anything else.

In your case, if A is actually an application (not a library) then specifying 
dependencies with [x.y] seems to be what you want; you will get exactly that 
version, or the build will fail if a dependency declares that it is not 
compatible with that version.

But if A is a library, then don't even try; libraries have no right to force 
specific versions on users of that library. The most they should do is declare 
minimum supported versions, with something like:
  [1.3,]

You may find the commands
   mvn dependency:list
   mvn dependency:tree
useful in tracking what depends on what.

NB: I'm no great expert on this area; double check before trusting my comments 
on this :-)

Regards, Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to specify local jars as dependencies?

[Simon Kitching]

 Andy Grove <[EMAIL PROTECTED]> schrieb:
> 
> Hi,
> 
> I'm currently updating a code generator product to generate maven build
> scripts as an alternative to Ant build scripts. Most of the dependencies in
> the generated java code are open source jars and I can use the maven
>  tags for those. However, the generated code also has
> dependencies on commercial jars (such as Oracle JDBC drivers) that can not
> go into a public maven repository and that I cannot distribute with my
> product. The user will already have these jars locally.
> 
> How can I tell maven to put these local jars on the classpath when compiling
> java code without using the dependency mechanism? I don't want to force
> users to set up their own local repositories or to have to run maven
> commands to install the jars in a local repository.

Sounds like a job for
  system

Regards, Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Make META-INF optional

[Simon Kitching]

That can be fixed by using the maven-buildhelper-plugin, which can attach any 
file to maven's list-of-deployable-files.

http://mojo.codehaus.org/build-helper-maven-plugin/index.html

 John Coleman <[EMAIL PROTECTED]> schrieb:
> Ah, this does not work, since the zip will not deploy to the m2 repo in the 
> deploy phase.
>  
> 
> > -Original Message-
> > From: John Coleman [mailto:[EMAIL PROTECTED] 
> > Sent: 29 January 2008 11:16
> > To: Maven Users List
> > Subject: RE: Make META-INF optional
> > 
> > Specifying pom packaging seems like an abuse, but if it 
> > works, then great!
> > 
> > Thanks,
> > John
> >  
> > 
> > > -Original Message-
> > > From: VUB Stefan Seidel [mailto:[EMAIL PROTECTED]
> > > Sent: 29 January 2008 11:05
> > > To: Maven Users List
> > > Subject: Re: Make META-INF optional
> > > 
> > > Hi John,
> > > 
> > > no, the assembly plugin can also generate just one single zip file.
> > > I use packaging _pom_ and this plugin def:
> > >
> > > maven-assembly-plugin
> > > 
> > >   
> > > package
> > > 
> > >   single
> > > 
> > >   
> > > 
> > > 
> > >   
> > > src/main/assembly/upload.xml
> > >   
> > > 
> > >   
> > > 
> > > On the other hand, there is an older maven zip plugin.
> > > 
> > > Stefan
> > > 
> > > John Coleman wrote:
> > > > Thanks, I was hoping to avoid assembly plugin because it
> > > seems to be added to a jar project. A direct zip plugin would make 
> > > more sense, but that's not a maven standard.
> > > >
> > > > John
> > > >  
> > > >
> > > >   
> > > >> -Original Message-
> > > >> From: VUB Stefan Seidel [mailto:[EMAIL PROTECTED]
> > > >> Sent: 29 January 2008 09:44
> > > >> To: Maven Users List
> > > >> Subject: Re: Make META-INF optional
> > > >>
> > > >> Would it help to create a ZIP file with the maven assembly
> > > plugin[1]?
> > > >>
> > > >> regards,
> > > >>
> > > >> Stefan
> > > >> P.S.: I just saw, the assembly plugin can also create JARs
> > > - so it's
> > > >> probably just what you need.
> > > >>
> > > >> [1] http://maven.apache.org/plugins/maven-assembly-plugin/
> > > >>
> > > >> John Coleman wrote:
> > > >> 
> > > >>> Hi,
> > > >>>
> > > >>> Is it possible to make a jar with no META-INF entry - I
> > > >>>   
> > > >> just want to
> > > >> 
> > > >>> create a jar to unpack with some files I need.
> > > >>>
> > > >>> TIA,
> > > >>> John
> > > >>>
> > > >>> Eurobase International Limited and its subsidiaries
> > > >>>   
> > > >> (Eurobase) are unable to exercise control over the content of 
> > > >> information in E-Mails. Any views and opinions expressed may be 
> > > >> personal to the sender and are not necessarily those of Eurobase.
> > > >> Eurobase will not enter into any contractual obligations
> > > in respect
> > > >> of any part of its business in any E-mail.
> > > >> 
> > > >>> Privileged / confidential information may be contained in
> > > >>>   
> > > >> this message and /or any attachments. This E-mail is
> > > intended for the
> > > >> use of the addressee(s) only and may contain confidential 
> > > >> information. If you are not the / an intended recipient, you are 
> > > >> hereby notified that any use or dissemination of this
> > > communication
> > > >> is strictly prohibited.
> > > >> If you receive this transmission in error, please notify us 
> > > >> immediately, and then delete this E-mail.
> > > >> 
> > > >>> Neither the sender nor Eurobase accepts any liability
> > > >>>   
> > > >> whatsoever for any defects of any kind either in or
> > > arising from this
> > > >> E-mail transmission. E-Mail transmission cannot be
> > > guaranteed to be
> > > >> secure or error-free, as messages can be intercepted, lost, 
> > > >> corrupted, destroyed, contain viruses, or arrive late or
> > > incomplete. 
> > > >> Eurobase does not accept any responsibility for viruses 
> > and it is 
> > > >> your responsibility to scan any attachments.
> > > >> 
> > > >>> Eurobase Systems Limited is the main trading company in the
> > > >>>   
> > > >> Eurobase International Group; registered in England and Wales as 
> > > >> company number 02251162; registered address: Essex House,
> > > >> 2 County Place, Chelmsford, Essex CM2 0RE, UK.
> > > >> 
> > > >>>
> > > >>>   
> > > >> 
> > > 
> > -
> > > >> 
> > > >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >>> For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>>
> > > >>>   
> > > >>>   
> > > >> --
> > > >> best regards, Stefan Seidel software developer 
> > > >>  VUB Printmedia GmbH Chopinstraße 4
> > > >> D-04103 Leipzig Germany tel. +49
> > > >> (341) 9 60 50 07 fax. +49 (341) 9 60 50 92 mail. 
> > > [EMAIL PROTECTED] web. 
> > > >> www.vub.de HRB Köln 24015 UStID DE 122 649 25

Re: Make META-INF optional

[Simon Kitching]

Yes, I would recommend this too.

A jarfile is not just a compressed bundle of files; it is an application or a 
library. Yes, the sun jar specification says that META-INF is optional, but why 
would you ever want to leave it out for an app or a library?

IMO, a compressed bundle of files without any metadata should be a .zip, not a 
.jar.

Regards, Simon

 VUB Stefan Seidel <[EMAIL PROTECTED]> schrieb:
> Would it help to create a ZIP file with the maven assembly plugin[1]?
> 
> regards,
> 
> Stefan
> P.S.: I just saw, the assembly plugin can also create JARs - so it's 
> probably just what you need.
> 
> [1] http://maven.apache.org/plugins/maven-assembly-plugin/
> 
> John Coleman wrote:
> > Hi,
> >
> > Is it possible to make a jar with no META-INF entry - I just want to
> > create a jar to unpack with some files I need.
> >
> > TIA,
> > John
> >

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANN] Maven Dependency Plugin 2.0 Released

[Simon Kitching]

Many thanks.

I think dependency:tree is possibly the best feature since maven 2.0.0.

 Erez Nahir <[EMAIL PROTECTED]> schrieb:
> Cograts !! that is great.
> 
> Erez.
> 
> On Jan 28, 2008 10:56 AM, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
> 
> > Congrats and big thanks! I'm sure there's been a lot of people waiting for
> > this plugin release, especially those interested in the dashboard, me
> > included.
> >
> > Kalle
> >
> >
> > On 1/25/08, Brian Fox <[EMAIL PROTECTED]> wrote:
> > >
> > > The Maven team is pleased to announce the 2.0 release of the Maven
> > > Dependency Plugin:
> > >
> > > http://maven.apache.org/plugins/maven-dependency-plugin
> > >
> > > This release fixes many issues and introduces several new goals for
> > > dependency analysis and output.
> > >
> > > Release Notes - Maven 2.x Dependency Plugin - Version 2.0
> > >
> > >
> > > ** Bug
> > > * [MDEP-59] - dependency:unpack can't extract rar archives
> > > * [MDEP-74] - dependencies in test scope are not handled properly by
> > > analyze
> > > * [MDEP-75] - non-portable classpath separator in build-classpath
> > > output
> > > * [MDEP-80] - Usage page of the docs use an overWrite property,
> > > but none exists in the (auto-generated) goal reference docs
> > > * [MDEP-81] - analyzer can't handle non-pom projects that don't
> > > produce a /target folder
> > > * [MDEP-83] - Typo in "How to prepare your dependencies before
> > > updating to Maven 2.0.6"
> > > * [MDEP-91] - org.codehaus.mojo:dependency-maven-plugin takes
> > > precedence over org.apache.maven.plugins:maven-dependency-plugin
> > > * [MDEP-93] - Tests can fail with OOME
> > > * [MDEP-95] - can't build unit tests with jdk1.4 rev 545703
> > > * [MDEP-97] - dependency:tree not consistent with maven core's
> > > dependency tree
> > > * [MDEP-113] - Unable to find the mojo
> > > 'org.apache.maven.plugins:maven-site-plugin:2.0-SNAPSHOT
> > > * [MDEP-120] - build-classpath is unable to build a classpath with
> > > runtime or test dependencies
> > >
> > > ** Improvement
> > > * [MDEP-89] - change separators in build-classpath
> > > * [MDEP-96] - Allow includes and excludes to be used
> > > simultaneously in the same filter
> > > * [MDEP-99] - Unpack SWC files
> > > * [MDEP-100] - Merge dependency:tree branch for new features
> > > * [MDEP-101] - Add dependency:list alias for dependency:resolve
> > > * [MDEP-104] - Add Analyze HTML Report
> > > * [MDEP-111] - Provide output on file as in other goals
> > > * [MDEP-119] - build-classpath should create destination directory
> > > for the classpath file
> > > * [MDEP-125] - Build-classpath should store the classpath in a
> > Filter
> > > * [MDEP-129] - allow substitution of the absolute local repo path
> > > with a property
> > > * [MDEP-130] - allow the classpath file to be attached
> > > * [MDEP-131] - Complete i18n support for new analyze-report
> > > * [MDEP-132] - Add german translation for analyze-report mojo
> > > * [MDEP-133] - Add dedicated resource bundle for locale "en"
> > >
> > > ** New Feature
> > > * [MDEP-47] - Ability to have an includes/excludes feature on the
> > > dependency:unpack goal.
> > > * [MDEP-70] - add new mojo to perform analysis of dependencies and
> > > fail the build if certain conditions aren't met
> > > * [MDEP-71] - add report to display contents of dependency-analyzer
> > > * [MDEP-94] - Add dependency:tree goal
> > > * [MDEP-116] - [dependency :copy-dependencies ] Add parameter to
> > > allow extracting POMs
> > >
> > > -
> > > 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: Conditionally including a jar file

[Simon Kitching]

The commons-logging pom for version 1.1 is screwed up [1].
Upgrade your dependency to 1.1.1 and the problem should go away.

[1] commons-logging 1.1 was not build with maven, and so was not in the maven 
repo. Some external person helpfully provided a pom and installed it into the 
main repo - but unfortunately marked all the optional dependencies as 
mandatory. So that 1.1 pom pulls in every library that commons-logging *can* 
support :-(

Regards, Simon

 Wayne Fay <[EMAIL PROTECTED]> schrieb:
> Commons-logging is a completely different artifact from log4j. But
> there is a possibility that c-l is pulling in log4j as a transitive
> dependency.
> 
> Try adding provided to the c-l dep, see what happens,
> and report back.
> 
> Wayne
> 
> On 1/24/08, Holt, Jack C. <[EMAIL PROTECTED]> wrote:
> >
> > I would like to not include the jar file for log4j when producing a WAR
> > file but allow it to be used when running my web app in Jetty.
> >
> > You see, JBoss includes a jar for log4j (a different version than I have
> > set up a dependency for in my POM file) and it causes errors when the
> > WAR file is deployed in JBoss.  I have been manually removing the log4j
> > file after the WAR file is generated.
> >
> > I have the following dependency in my POM file which I believe is the
> > reason the log4j jar file is showing:
> >
> > 
> > commons-logging
> > commons-logging
> > 1.1
> > 
> >
> > Do I need to somehow configure this as a dependency of the Jetty plugin
> > and remove it as a dependency of the project?
> >
> > -
> > 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]

Re: maven-jar-plugin and maven-ejb-plugin / generate manifest if not present

[Simon Kitching]

Maybe you could set the  settings to 
target/resources/META-INF/MANIFEST.MF (or whatever the right path is), and then 
use maven filtering to transform the "template" in src/main/resources into the 
form you want.

Regards,
Simon

 Julien CARSIQUE <[EMAIL PROTECTED]> schrieb:
> Sorry, I didn't list all the tests I've done.
> I tried what you suggest, the result is a jar containing a new manifest 
> with the wanted manifest entries from pom.xml but without all the 
> content of the manifest present in src/main/...
> 
> While doing this, I'm trying to manage with the buildnumber plugin in 
> order to have manifest containing unique Bundle-Version; which is 
> required by Eclipse when some of our artifacts are used as plugins.
> 
> Being able to add entries from pom to an existing (or not) manifest 
> would be very useful for this.
> 
> Wayne Fay a écrit :
> > Try removing the  entry and see what happens when
> > there's a file present in that location, and what happens when there's
> > not (check target to see what ends up in the JAR). By default, Maven
> > looks for the file in that location, and uses it if its there, or
> > generates one if there's not.
> >
> > I'm honestly not sure that adding a manifestEntry will work when the
> > file is present, but sounds like another thing to try while you're
> > doing the tests I suggested above.
> >
> > Wayne
> >
> > On 1/24/08, Julien CARSIQUE <[EMAIL PROTECTED]> wrote:
> >   
> >> Hello,
> >>
> >> I would like the plugin to use the given manifest, if present, and add
> >> some properties; and to generate the manifest if it doesn't exist.
> >> Is it possible ?
> >>
> >> Here is my common configuration in the parent pom :
> >> 
> >>   org.apache.maven.plugins
> >>   maven-jar-plugin
> >>   2.2
> >>   
> >> 
> >>
> >> src/main/resources/META-INF/MANIFEST.MF
> >>   
> >> ${pom.version}
> >>   
> >> 
> >>   
> >> 
> >>
> >> For now, if there's no manifest in the specified place, I got this error :
> >> [ERROR] BUILD ERROR
> >> [INFO]
> >> 
> >> [INFO] Error assembling JAR
> >>
> >> Embedded error: Manifest file:
> >> .../src/main/resources/META-INF/MANIFEST.MF does not exist.
> >>
> >> Of course, the aim is to have a generic configuration, in order not
> >> having to specify for each artifact if there's a manifest, or none.
> >>
> >>
> >> Thanks,
> >> Julien
> >>
> >> --
> >> Julien CARSIQUE, Nuxeo (Paris, France)
> >> Open Source Enterprise Content Management - http://www.nuxeo.org/
> >> Nuxeo EP 5: extensible, Java EE and standards based ECM Platform
> >> http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
> >>
> >>
> >> -
> >> 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]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: multimodule classpath

[Simon Kitching]

 John Coleman <[EMAIL PROTECTED]> schrieb:
> Hi,
> 
> Is it possible to get a classpath for a multimodule project that
> contains all the subproject target/class folders?

What would be the point of that?

Each module has exactly the classpath it needs, dynamically computed by maven 
using the declared dependencies.

If a module Bar needs to build something using the classpath present in module 
Foo, then Bar should just declare Foo as a dependency and then that will 
automatically happen (well, for the bits that *should* be inherited from Foo, 
as declared in its pom).

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: MJAR-90 and empty jar files

[Simon Kitching]

Hi Robert,

Oliver's proposal seems fine to me.

Whatever file you put in the resources directory will just get copied 
byte-for-byte. So if you want a zero-sized file, put a zero-sized file there. 
If you want a valid jar with no contents, then create one and put it in the 
resources dir.

What are you trying to achieve that this doesn't do?

Regards,
Simon

 [EMAIL PROTECTED] schrieb:
> That would create the jar, but it would not be physically empty, only 
> functionally empty.
> 
> Robert Egan
> 
> [EMAIL PROTECTED] wrote on 01/24/2008 07:44:36 AM:
> 
> > Hi,
> > Should work with adding a dummy/empty resource file in 
> src/main/resources.
> > 
> > --
> > Olivier
> > 
> > 2008/1/24, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > > First, I want to thank everyone who made 2.2 a reality. It's let me
> > > cleanup my build quite a bit.
> > >
> > > Having said that, it seems that you can't please everybody all of the
> > > time, especially with a generic tool like the maven-jar-plugin .
> > >
> > > I have a business requirement (read: management, not programmatic,
> > > decision)  to produce a few empty jars in my build. I had hoped the
> > >  configuration option would do the trick, but it 
> doesn't.
> > >
> > > Since the jars are empty I do not need any 2.2 specific functionality, 
> so
> > > I can force 2.1 using  as a workaround.
> > >
> > > Is there a cleaner way?
> > >
> > >
> > > Robert Egan
> 
> --
> This email message and any attachments may contain confidential, 
> proprietary or non-public information.  The information is intended solely 
> for the designated recipient(s).  If an addressing or transmission error 
> has misdirected this email, please notify the sender immediately and 
> destroy this email.  Any review, dissemination, use or reliance upon this 
> information by unintended recipients is prohibited.  Any opinions 
> expressed in this email are those of the author personally.
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JUnit tests requiring j2ee.jar fail when running mvn surefire:test

[Simon Kitching]

 Stephen Connolly <[EMAIL PROTECTED]> schrieb:
> Don't use the borked j2ee.jar from the java.net or java.net2 maven
> repositories.
> 
> I had the same problem.  Basically, the j2ee.jar on the java.net repos is
> not a real jar, just stripped classes that have no method bodies, but just
> the method definitions.
> 
> The borked jar is only good for compiling. I had an argument with the guy
> who posted it where I pointed out
> "why-the-f*ck-would-you-want-a-jar-that-you-cannot-run-unit-tests-against-in-a-maven-repository"
> and he seemed to think that not running unit tests was a perfectly valid use
> case and sure nobody using maven runs unit tests all the time, and sure
> could they not just compile and package the jar...
> 
> He did not seem to get the whole lifecycle thing about maven2 at all

Sigh. Thanks for trying Stephen..

Wouldn't this be a good case for a classifier? eg 
  apionly

Then people who want this strange compile-but-not-run dependency can have it...

Regards, Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about dependence transfer

[Simon Kitching]

 Guillaume Lederrey <[EMAIL PROTECTED]> schrieb:
> On 17/01/2008, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > Suppose your project depends on class Foo from project p1 (and so declares 
> > a compile-scope dependency on p1).
> >
> > But class Foo extends class Base from project p2 (and so p1 has a 
> > compile-scope dependency on p2). So project p2 (even though it is a 
> > transitive dependency) is needed at compile time for your code.
> 
>   I have a related question / remark : Imagine a Maven module that is
> used as a library. This library has classes that are part of a public
> interface, and classes the are the actual implementation. The
> implementation can depend on other artifacts to compile, but those
> artifacts should not be needed to compile a project depending on our
> library.
> 
>   Of course, the right thing to do is to split the library in an "api
> module" and an "implementation module". But imagine that you have
> legacy code that didnt follow this separation (everybody knows that
> bad design never happens in real life project ;-). Would it be
> possible to declare a compile time dependency that will not be
> transitive ? Or that will only be a runtime dependency transitively ?

What you could possibly do is create a profile that you would use for 
compiling. In this profile, add the problem dependencies with scope of 
"compile". But in the main part, add the problem dependencies with scope of 
"runtime", so that projects which just *use* your code (via its pom) see the 
lib as just a runtime dependency, not a compiletime one.

I'm not sure if it's possible to have the same dependency twice (which will 
happen when the profile is active) but it might be worth trying..

Regards, Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about dependence transfer

[Simon Kitching]

Suppose your project depends on class Foo from project p1 (and so declares a 
compile-scope dependency on p1).

But class Foo extends class Base from project p2 (and so p1 has a compile-scope 
dependency on p2). So project p2 (even though it is a transitive dependency) is 
needed at compile time for your code.

P2's runtime dependencies will not be needed, so I suppose those are not 
fetched.

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Cheers, Simon

 Nick Stolwijk <[EMAIL PROTECTED]> schrieb:
> Then I was wrong there. I thought when maven needs a dependency for 
> compilation, it wouldn't need the transitive dependencies.
> 
> With regards,
> 
> Nick Stolwijk
> 
> Simon Kitching wrote:
> > Nick: for maven2, if a pom declares a dependency on something that itself 
> > has non-optional dependencies, then they should get *immediately* 
> > downloaded.
> >
> >   
> >
> 
> -
> 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: about dependence transfer

[Simon Kitching]

Nick: for maven2, if a pom declares a dependency on something that itself has 
non-optional dependencies, then they should get *immediately* downloaded.

cmd: is the small bit of config you originally posted nested inside a 
 section? If so, that is wrong.

Otherwise, please tell us why you think the dependencies of the 
org.springframework:spring library have not been downloaded.

Regards, Simon

 [EMAIL PROTECTED] schrieb:
> You give not so much information, but I think I know why Maven didn't 
> downloaded the dependencies. Because it didn't have to.
> 
> It wil only download dependencies if it has too. If you specify a dependency 
> and need the transitive dependencies for compile time, you will need to add 
> them yourself. You are depended on them, so you need to specify that. Else 
> your code breaks if a newer version of another dependency stops being 
> depended on it.
> 
> If you have further questions, please be more descriptive about what you are 
> trying to do. 
> 
> Hth,
> 
> Nick Stolwijk
> 
> -Original Message-
> From: cmd [mailto:[EMAIL PROTECTED]
> Sent: Thu 1/17/2008 3:47 PM
> To: users@maven.apache.org
> Subject: about dependence transfer
>  
> 
> i use maven2 to manage my jars
> like this
> 
>   org.springframework
>   spring
>   2.5.1
> 
> 
> but springframework depend some jars.Maven has not download the jars
> automatic.
> now how can i set the config file?
> 
> -- 
> View this message in context: 
> http://www.nabble.com/about-dependence-transfer-tp14920281s177p14920281.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]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using unreleased plugin

[Simon Kitching]

 "Rémy Sanlaville" <[EMAIL PROTECTED]> schrieb:
> Try this command :
> mvn
> org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree

That did it. Thanks very much!


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Using unreleased plugin

[Simon Kitching]

Hi,

I'd like to run the "dependency:tree" goal against a local project. According 
to the docs, this goal is only available in 2.0-alpha-5 or later. But that 
isn't out yet. 

There is an alpha-5-SNAPHOT though:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-dependency-plugin/
and I see that some people are already using the dependency:tree feature so 
presume that they are using this snapshot.
  
I have therefore defined the apache snapshot repository in my settings.xml, 
under a profile called "apache" as documented on the maven site:

  

  apache
  

  apache.org
  Maven Snapshots
  http://people.apache.org/repo/m2-snapshot-repository
  
false
  
  
true
  

  
  

  apache.org
  Maven Plugin Snapshots
  http://people.apache.org/repo/m2-snapshot-repository
  
false
  
  
true
  

  

  

But when I run
  mvn -U -Papache dependency:tree
I still get
  [INFO] Required goal not found: dependency:tree

Running with -X says:
[DEBUG] maven-dependency-plugin: resolved to version 2.0-alpha-4 from 
repository central

Running
  mvn -Papache -Pnosuchprofile help:active-profiles
gives
  The following profiles are active:
  - apache (source: settings.xml)
so it looks like that is being picked up ok.

What am I missing?

Thanks,
Simon
  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Resources from classpath in JAR

[Simon Kitching]

 dddzzz <[EMAIL PROTECTED]> schrieb:
> 
> 
> 
> Heinrich Nirschl wrote:
> > 
> > 
> > Put them into src/main/resources.
> > 
> > 
> 
> I want them to be in same folder that classes are.

That's a reasonable way to structure your code I think. I always used to put 
resources together with the code that used them.

However maven doesn't support that by default; instead it assumes that runtime 
resources are kept in a separate directory tree from the source. If you want to 
have everything combined, you need to explicitly configure the resources 
directory, together with filters to filter out the files that you do not want 
copied (eg *.java).

I *guess* that the reason why maven has this default behaviour is that the 
final jar that is to be build (normally) contains .class files plus runtime 
resources, *but not source code*. That means that the build tool would need to 
determine which files in the source-code directories adddzzz <[EMAIL 
PROTECTED]>re "source code" that should not be in the final jar, and which 
files are "runtime resources" that should be in the final jar. That is not just 
a matter of excluding "*.java", so users would need to add configuration to 
state what they want and what they don't want. Having a separate resource dir 
avoids the need for this configuration.

But in summary, if you want one combined source and resources dir, you will 
need extra config in your pom to set that up.

Regards,
Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Setting Java System property

[Simon Kitching]

 Simon Kitching <[EMAIL PROTECTED]> schrieb:
>  Matthew Tordoff <[EMAIL PROTECTED]> schrieb:
> > Thanks for that but I have already looked at the appropriate
> > documentation. I have tried setting the system property in all of those
> > locations and for some reason none of the settings are passed through. I
> > did find a JIRA bug opened against this problem somewhere, and thus am
> > guessing this functionality isn't yet available.
> 
> Are you trying to set a "global" property, or one specific to just a 
> particular plugin?
> 
> You appear to be trying to do the latter by nesting your properties info 
> inside a  tag. However the page I referred you to says about 
> configuration:
>   The configuration as DOM object.
> which strongly implies to me that this is only interpreted by the plugin, and 
> you cannot assume that maven looks in here, ie the plugin alone is 
> responsible for interpreting the contents. I could be wrong here, but don't 
> think so..
> 
> Setting properties in a pom which are global to all stuff in the pom (and 
> child poms) is trivial, and definitely works when *not* nested within a 
>  element (as documented in the page I referred you to):
> 
> 
>  ...
>  
>fooval
>  
> 
> 
> It also works in settings.xml, but you do need to be sure that the profile it 
> is defined within is active..
> 

Ah..hang on a minute. Your original mail said:

 Setting in the above way is the only way in which I appear to be able to
access the file at a later stage from one of my MOJOs via
System.getProperty("systemprop") .


So your problem is not setting properties that you then reference via 
"${propname}" in your pom, but that you want to access them from a custom maven 
plugin?

I don't think that maven properties get stored into the "system properties" 
object. I haven't written any custom maven plugins myself, but expect your 
custom plugin code will need to look up maven properties using a maven api (or 
have plexus inject it) rather than using System.getProperty.

Regards, Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Setting Java System property

[Simon Kitching]

 Matthew Tordoff <[EMAIL PROTECTED]> schrieb:
> Thanks for that but I have already looked at the appropriate
> documentation. I have tried setting the system property in all of those
> locations and for some reason none of the settings are passed through. I
> did find a JIRA bug opened against this problem somewhere, and thus am
> guessing this functionality isn't yet available.

Are you trying to set a "global" property, or one specific to just a particular 
plugin?

You appear to be trying to do the latter by nesting your properties info inside 
a  tag. However the page I referred you to says about 
configuration:
  The configuration as DOM object.
which strongly implies to me that this is only interpreted by the plugin, and 
you cannot assume that maven looks in here, ie the plugin alone is responsible 
for interpreting the contents. I could be wrong here, but don't think so..

Setting properties in a pom which are global to all stuff in the pom (and child 
poms) is trivial, and definitely works when *not* nested within a 
 element (as documented in the page I referred you to):


 ...
 
   fooval
 


It also works in settings.xml, but you do need to be sure that the profile it 
is defined within is active..

Regards,
Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Setting Java System property

[Simon Kitching]

http://maven.apache.org/ref/current/maven-model/maven.html

Search for "properties".

 Matthew Tordoff <[EMAIL PROTECTED]> schrieb:
> I still haven't moved forwards with this. Does any one have any ideas? 
> 
> -Original Message-
> From: Matthew Tordoff [mailto:[EMAIL PROTECTED] 
> Sent: 14 January 2008 17:56
> To: Maven Users List
> Subject: Setting Java System property
> 
> Hi all,
>  
> I am having problems setting a Java System Property as part of my build.
> I have tried setting it in all kinds of places and the only one that I
> have found to work is setting it as part of the maven command line as
> follows:
>  
> mvn compile -Dsystemprop=blah
>  
> Setting in the above way is the only way in which I appear to be able to
> access the file at a later stage from one of my MOJOs via
> System.getProperty("systemprop") .
>  
> I don't want to have to set this at the command line because I want to
> minimise what is typed each time mvn is run.
>  
> The other approaches I have tried are...
>  
> Within pom.xml
> - 
> blah
>
>  
> also...
>  
> 
>   
> blah
>   
> 
>  
> within settings.xml...
>  
>   
> blah
>   
>  
> Any help would be greatly appreciated.
>  
> Regards,
>  
> Matt
> 
> 
> 
> The content of this e-mail is confidential and may be privileged. It may
> be read, copied and used only by the intended recipient and may not be
> disclosed, copied or distributed. If you received this email in error,
> please contact the sender immediately by return e-mail or by telephoning
> +44 20 7260 2000, delete it and do not disclose its contents to any
> person. You should take full responsibility for checking this email for
> viruses. Markit reserves the right to monitor all e-mail communications
> through its network.
> Markit and its affiliated companies make no warranty as to the accuracy
> or completeness of any information contained in this message and hereby
> exclude any liability of any kind for the information contained herein.
> Any opinions expressed in this message are those of the author and do
> not necessarily reflect the opinions of Markit.
> For full details about Markit, its offerings and legal terms and
> conditions, please see Markit's website at http://www.markit.com
>  .
> 
> 
> 
> The content of this e-mail is confidential and may be privileged. It may be 
> read, copied and used only by the intended recipient and may not be 
> disclosed, copied or distributed. If you received this email in error, please 
> contact the sender immediately by return e-mail or by telephoning +44 20 7260 
> 2000, delete it and do not disclose its contents to any person. You should 
> take full responsibility for checking this email for viruses. Markit reserves 
> the right to monitor all e-mail communications through its network.
> Markit and its affiliated companies make no warranty as to the accuracy or 
> completeness of any information contained in this message and hereby exclude 
> any liability of any kind for the information contained herein. Any opinions 
> expressed in this message are those of the author and do not necessarily 
> reflect the opinions of Markit.
> For full details about Markit, its offerings and legal terms and conditions, 
> please see Markit's website at http://www.markit.com  
> .
> 
> -
> 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: Is there a problem with surefire-junit-2.4?

[Simon Kitching]

 Ben Lidgey <[EMAIL PROTECTED]> schrieb:
> Some of our builds here have started failing today as it is unable to 
> download surefire-junit-2.4-SNAPSHOT artifact. Is there an issue with this?

> org.apache.maven.surefire:surefire-junit:jar:2.4-SNAPSHOT
> 
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2),
>   appfuse (http://static.appfuse.org/repository)
> 

That's a snapshot file you're trying to download, but I don't see any snapshot 
repository listed. It certainly won't be in the main maven repo, as that's only 
for released code.

Regards,

Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release plugin for multiple projects with dependencyManagement in parent pom.xml

[Simon Kitching]

 Guillaume Lederrey <[EMAIL PROTECTED]> schrieb:
> On 11/01/2008, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > I've never really understood why the dependencyManagement section is useful 
> > at all.
> >
> > Why not just have each module declare the minimum version of a library that 
> > *it* needs in order to compile and pass the unit tests?
> >
> > Why would you ever want to omit the version tag? That just seems to be 
> > deliberate obfuscation.
> 
> It is important in some organizations (like where I am working now)
> where dependency management is not (and should not be) in the hand of
> the developers. The developers are handed a list of version that they
> should be using. If there is a clear separation of concern, it should
> be reflected in the code ...

IMO this is better handled by having a company repository that the parent pom 
points to, and having the default repos (repo1.maven.org etc) disabled. Then 
developers can only ever add dependencies into their poms that exist in the 
corporate repo. That's far more effective than just using dependencyManagement, 
which doesn't block child poms from (even accidentally) adding refs to 
artifacts that are not "permitted".

It's also possible for the parent pom to just define properties, that are 
referenced by child poms:
  ${foo.bar.version}
To me this seems better than dependencyManagement as it is clear in the parent 
poms that something *must* be defining an explicit version (ie giving that 
property a value), and if it isn't then that results in a build error.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release plugin for multiple projects with dependencyManagement in parent pom.xml

[Simon Kitching]

 Simon Kitching <[EMAIL PROTECTED]> schrieb:
> I've never really understood why the dependencyManagement section is useful 
> at all.

Just to clarify: I meant using it to define lib versions for child poms, with 
simple stuff like.
  
..
...
...
  

Obviously the ability to define default *configurations* of plugins that child 
modules can reference is very useful.

I guess one valid use for simple version declaration is to ensure that when you 
plan to release a product with version X of a lib, then that exact version is 
used when running the unit tests of every module, rather than just the "minimum 
required version" for that module. Of course for this to be effective, I 
believe the version tags need to be explicit version declarations using 
[2.2] otherwise you are not guaranteed to get that version 
anyway. And if exact versions are forced in the parent pom, it becomes pretty 
useless for release to public repositories.

I have proposed earlier a mechanism for "dumping" the resolved dependencies of 
a module to an external file, and a mechanism for forcing dependency resolution 
to use exact versions from an external file. This could then be used during 
release to solve the above issue; first dump exact dependencies for the 
artifact you want to release and inspect them to make sure they are what you 
expect. Then run the release plugin passing this file as an argument, which 
forces each module in the tree to build and test against exactly those versions.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Classpath order of dependencies

[Simon Kitching]

 Marco Huber <[EMAIL PROTECTED]> schrieb:
> Hello,
> 
> I have a little problem with the order of my dependencies.
> Depending on the posistion of one dependency I get an error during my tests.
> 
> The first pom snippet result in an NoClassDefFoundError:
> 
> ...
> 
> org.hibernate
> hibernate-validator
> 3.0.0.ga
> 
> 
> 
> org.jboss.embedded
> hibernate-all
> beta2
> 
> ...
> 
> 
> If I change the order of this two dependencies I get not error.
> 
> Is the order in the pom the crucial factor on how the classpath is build 
> in maven? Or is it possible that transient dependencies overwrites 
> direct dependencies?

I believe that Maven calculates the order of libs in the classpath based upon 
the declared dependencies, and that the order of dependency entries in the pom 
doesn't normally matter. I've certainly not had this problem before, and have 
never cared about the order of dependency entries in poms.

My guess is that the pom for hibernate-validator is wrong, and has left out a 
dependency. Of course if that is the case, then a maven project using that pom 
would not build - but perhaps the jboss people don't use maven for building and 
just create poms by hand for maven users.

If you really care about the cause of this, then perhaps run with
  java -verbose:class
to see what class wants what class. I presume a hibernate-validator class will 
be the cause of the problem. Then have a look at whether the missing class is 
in the dependencies of hibernate-validator's pom.

Regards,
Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release plugin for multiple projects with dependencyManagement in parent pom.xml

[Simon Kitching]

 Aleksandras Skrynikovas <[EMAIL PROTECTED]> schrieb:
> Hi, I've browsed the mailing list for a solution but there doesn't  
> seem to be a clear cut answer.
> 
> Problem: in my app many projects depend on a single parent which uses  
> dependencyManagement to keep
> module versions nice and tidy. When releasing some project with the  
> release plugin, I have to update the
> version of that project in the dependencyManagement element of the  
> parent pom as I understand,
> which leads to a new version of the parent itself, but how can I  
> avoid having to manually increment the parent version
> in all child poms?
> 
> I've read in a couple of places that the release plugin somehow  
> handles this but haven't been able to find any documentation
> of explanation. If there is no pretty solution, what could be the  
> most viable workaround?

Currently, either the updates are done manually in the children, or the 
maven-release-plugin is used, which just does automatically the same tasks that 
could be done by hand. However the maven-release-plugin can only be used if the 
children of the released parent are actually in the same directory tree in the 
version control repository, and if the children are released at the same time 
as the parent.



I've never really understood why the dependencyManagement section is useful at 
all.

Why not just have each module declare the minimum version of a library that 
*it* needs in order to compile and pass the unit tests? 

Why would you ever want to omit the version tag? That just seems to be 
deliberate obfuscation.

When someone uses this module in another project, any library that is the 
target of multiple dependencies just gets automatically resolved as the max 
value of all the versioned references to it. So what version a *user* of this 
module gets depends on the "global needs", but that's a different issue and is 
handled fine by Maven. The pom of the original module, however, is still being 
"true to itself" and honestly declaring exactly what its requirements are.

A pom then only ever updates its  reference to a dependency if it is 
modified in such a way that it needs the new version. Otherwise leave it alone.

This then completely does away with the need to release new versions of parent 
poms just in order to update dependencyManagement versions.

If you're building a final distribution bundle for product, then that *final* 
pom may choose to lock down all the dependencies to specific versions. But that 
is then being done at a *leaf* of the tree, not at the *root* so changes don't 
trigger cascading problems throughout the parent/child chain.

Otherwise, what possible reason is there for requiring a tree of modules to use 
the same dependency version?


And for plugins, IMO every plugin reference in a pom should specify the version 
exactly, and maven should always provide exactly that version (ignoring any 
parent). If that version of the plugin is sufficient to correctly build the 
project, why would you ever want anything different? That is just asking for 
trouble. App libs need dependency resolution because only one copy can be 
present in the classpath of the final app. However that constraint doesn't 
apply to plugins; each module can have its own private version that suits it.

And if dependencyManagement is not used then the parent pom only needs updating 
if it adds functionality that the child actually wants, eg binding a new plugin 
or adding a new report. Children that *want* that functionality should then be 
updated to point to the new parent.

Have I missed something here? [I'm not a maven newbie, but not a pro either. 
Any corrections happily accepted...]

Regards,

Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven2 build and package targets' classpath

[Simon Kitching]

 Filipe David Manana <[EMAIL PROTECTED]> schrieb:
> Hi,
> 
> I want to add a JAR archive to the CLASSPATH for the targets build/package.
> I don't want to include that JAR archive in my final WAR file. I read the
> documentation, and for that purpose I added in my pom.xml the following to
> the  element:
> 
>
>   
> oracle
> oracle-jdbc
> 14
>   
> 
> 
> This artifact was successfully added by me doing:
> 
> mvn install:install-file
> -Dfile=/opt/oracle/product/10g/jdbc/lib/ojdbc14.jar  -DgroupId=oracle
> -DartifactId=oracle-jdbc  -Dversion=14  -Dpackaging=jar
> 
> 
> Although when I run "mvn package" or "mvn compile" I get errors telling that
> the packages/classes defined in that JAR archive were not found in the
> classpath.
> 
> How can I achieve this?

I believe the "extensions" attribute is intended to make "dynamically 
discoverable" libraries available to maven plugins.

In your case, probably what you want is
  provided
which tells maven that the jar is needed for compilation and for tests, but 
that the environment the artifact will finally be deployed into already 
provides a copy of this so it should not be in the final bundle.

Or maybe scope "optional" is what you are looking for. Again, optional jars are 
not in the final bundle although they are present in the classpath for compile 
and test phases.

Regards,
Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Excluding files from JAR

[Simon Kitching]

 amit kumar <[EMAIL PROTECTED]> schrieb:
> Just like WAR can I as well exclude some files from JAR builds as well?

Not until the next version of the jar plugin is released.

For the moment, the usual workaround is to use the antrun plugin to remove the 
unwanted files before the jar is created.

Regards, Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: site plugin with sub module

[Simon Kitching]

 globulon <[EMAIL PROTECTED]> schrieb:
> 
> I am using the latest version of the maven site plugin.
> 
> In the site.xml file of the top parent project I have introduced the
> following :
> 
>   
>   
>   
> 
> 
> as a special menu to new projects.
> 
> I have two problems.
> 
> The site generated from sub project exhibit this menu. I have tried to
> override it. Impossible,
> it is still appearing.

It should not appear unless the child has a menu of the same name, with the 
"inherit" flag set. You really have no menu of this name in the child site.xml?

> Moreover the introduction of the '/' character is not enough to allow
> navigation relatively to the root
> site project.
> Generated HTML source show links as:
> 
> xxx-project/index.html
> 
> and 
> 
> xxx2-project/index.html

Yes, url handling in site.xml is just *weird* in my experience.
The only solution I know of that works is to specify all urls as absolute 
paths. When the site is generated, any url that starts with a value matching 
the  tag in the pom is then transformed into a relative url in the 
generated site.

Having all the paths as absolute values in site.xml is pretty ugly though. I 
would love to hear of a better solution.

Regards, Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: how to add additional path to the compiler ?

[Simon Kitching]

 garyng <[EMAIL PROTECTED]> schrieb:
> 
> I followed this
> 
> http://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-compiler-arguments.html
> 
> but it seems that it is being ignored/eaten.
> 
> What I want is to include the "src/main/webapp/WEB-INF/lib" to the compiler
> classpath as there are libraries not managed in maven.
> 
> I believe this is pretty standard situation.
> 
> -classpath src/main/webapp/WEB-INF/lib"
> 
> would results in javac error
> 
> 
> src/main/webapp/WEB-INF/lib
> 
> 
> doesn't seem to be passed to javac, even though the mvn -X dump shows that
> it has been picked up by the plugin.
> 
> I am wondering if the feature has even been tested before ? 

Adding libs to the classpath directly, bypassing maven, is not the right way to 
do things. I suspect you'll find that *other* compiler arguments work fine, but 
that classpath is not passed through because Maven wants to set that itself.

You probably should declare these extra jars as normal  sections in 
your pom. If you absolutely have to, then use 
  system
  ..
although "normal" maven dependency resolution via the repository is better 
wherever possible.

I haven't tried it, but maybe 
  ${project.basedir}/
could be used in the systemPath section if the files are checked in within a 
subdir beneath the pom.

Regards,

Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Continuum: what does default mean?

[Simon Kitching]

Hi,

On a continuum site, what does the "default" setting mean for a project?

Thanks, Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: A question about in in pom.xml

[Simon Kitching]

 Heinrich Nirschl <[EMAIL PROTECTED]> schrieb:
> On Jan 2, 2008 12:06 PM, Thomas Chang <[EMAIL PROTECTED]> wrote:
> > Now I do as follow in the "settings.xml":
> >
> >   
> >   
> >   
> >   3.8.1
> >   
> >   
> >   
> >
> >   And it runs successful when I run "mvn clean". But as I run "´mvn 
> > compile" I got error as follow:
> >
> >   Downloading: 
> > http://repo1.maven.org/maven2/junit/junit/{my.junit.version}/junit-
> > {my.junit.version}.jar
> 
> To reference the proerties you must use syntax like this:
> 
> ${my.junit.version}

And you need to make sure the profile it is defined in is "active". By default, 
profiles are not active so variables defined in them have no effect. Use 
"-Pprofilename" on the commandline, or set  (name might not be 
quite right) in the profile definition.

Regards,

Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release killed by site config/how do you create multi module site with correct links?

[Simon Kitching]

Hi Paul,


Sundling, Paul wrote:
> 
> Already wasted over a day on this, so maybe someone else can give me an
> idea how to do it.  There are two parts to this, generating a site of a
> multi module project with the correct links and the strange failure I
> get when doing a release if site config is present.
>  
> Genering multi module project and have the sub project links work
> correctly...
>  
> Imagine a multi module project with two modules, built by invoking maven
> in the parent directory.  Below are the file locations for the generated
> sites without url specified and the link in the parent module's site.
> They don't match up for site:site or site:stage-deploy.
>  
> myproject
> myproject/subproject1
> myproject/subproject2  (depends on subproject1)
>  
> mvn site:site
> the result is (caps added to targets for emphasis)
>  
> site files:
> myproject/target/site
> myproject/subproject1/target/site
> myproject/subproject2/target/site
>  
> links:
> myproject/target/site
> myproject/target/site/subproject1
> myproject/target/site/subproject2
>  
> myproject   ::{myproject}/target/site   ::
> subproject1::{myproject}/subproject1/target/site ::
> {myproject}/subproject1
>  
>  
> mvn site:stage-deploy -DstagingDirectory=/tmp/myproject/site
> result is:
>  
> site files:
> /tmp/myproject/site/staging
> /tmp/myproject/subproject1/staging
> /tmp/myproject/subproject2/staging
>  
> links (note subprojects ordering is switched and link fails):
> /tmp/myproject/site/staging
> /tmp/myproject/site/staging/subproject1
> /tmp/myproject/site/staging/subproject2
>  
> Weird failure during release:perform =>
>  
> mvn site:deploy
> give links with proper URLs to subproject if their  section is not
> specified if I add a section like this:
>  
>   
>...   
>   
>   myproject-site
>   Myproject Site
>   file:///tmp/myproject/site
> 
>   
>  
> This gives me what I want with the major drawback of breaking the
> ability to release a new version!!
>  
> Adding that site section causes release:perform to fail:
> mvn clean install  
> mvn -B  -Dresume=false -Dmaven.test.skip release:prepare  
> mvn -B -Dmaven.test.skip release:perform 
>  
> It fails during release:perform because it can't find subproject1 which
> is needed for subproject2 during site:site.
>  
> Removing the site section again and release:perform works once again.
>  
> So what is the right approach.  I looked through pom files setting url
> in their site section and not one used file://, only scp://  for their
> url.  Is that the problem?
>  
> I need to use relative paths because the site will be hosted with the
> builds using cruise control.
> 
> 

It's probably no consolation, but I have been struggling with this problem
too.

I'm trying to test modifications to site.xml, but when using site:stage,
relative links in menu items of the site.xml just get badly screwed up.

Thanks for the tip on modifying pom.xml to use a file: url, that works for
me. At least I can now test the site modifications I'm making.

I wonder whether perhaps windows paths like
  -DstagingDirectory=c:\foo
are being detected as "absolute" paths, but unix paths like
  -DstagingDirectory=/tmp/foo
are not. That would explain why "file:///..." then works.

Unfortunately,
  -DstagingDirectory=file:///tmp/foo
is not accepted.

Paul, as a workaround maybe you could consider defining a profile with your
modified distributionManagement section? Then you could use
  mvn -PtestSite site:stage
for testing (triggering the file:// destination).

Any info from the maven experts on this would be greatly appreciated..

Regards,

Simon
-- 
View this message in context: 
http://www.nabble.com/Release-killed-by-site-config-how-do-you-create-multi-module-site-with-correct-links--tp14465833s177p14556863.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]

p tags lost after ul tag

[Simon Kitching]

Hi,

I'm trying to update xdoc-format docs for the myfaces-orchestra project
but have encountered something weird.
Of course I'm using "mvn site" to build the website.

But when I have
  
   foo
  bar
 
para1
para2
in the document then the  and  tags following the list are not
present in the generated output. If I comment out the list, then they
reappear.

I'm pretty sure my input is well-formed, firstly because I've looked
quite carefully and second if it isn't then an error is output anyway.

I think "doxia" is the component responsible for processing xdoc files.
Am I right?
And am I doing something wrong, or is this a bug?

Thanks,

Simon

Re: accessing artifacts in local repository from pom expressions or antrun scripts

[Simon Kitching]

Maybe use the maven-dependency-plugin, which according to the docs can
copy the set of dependencies to an arbitrary directory, and strip off
version numbers?

On Thu, 2006-08-03 at 00:25 +1000, J. Matthew Pryor wrote:
> I am using the native-maven-plugin to compile C source for the ATmelplatform
> This produces two binary/object files as artifacts from sibling modules. I 
> need to be able to pass the path names of these 2 files to a
> Java program we have written that merges the 2 object files together
> 
> Thanks for any further assistance
> Matthew
> 
> 
> 
> 
> Denis Cabasson wrote:
> > Merging 2 artifacts
> >
> > Looks like a task for maven-assembly-plugin:
> > http://maven.apache.org/plugins/maven-assembly-plugin/unpack-mojo.html
> >
> > It can unpack jar/zip dependencies to an assembly directory and package them
> > as you need.
> >
> > I'm afraid I can't help any futher without more informations about the
> > artifacts you want to merge, and what you want to produce.
> >
> > Denis.
> >
> >
> > J. Matthew Pryor wrote:
> >   
> >> I am migrating a maven 1 project to a maven 2 project.
> >> I have one module that creates its artifact by merging together 2 
> >> artifacts created by dependent modules
> >> At the moment, I am trying to do it all with the antrun plugin, rather 
> >> than writing Mojos.
> >>
> >> In the maven 1 version I did somethign like this:
> >>
> >> ${maven.repo.local}/${pom.artifactDirectory}/the-file-i-want.exe
> >>
> >> Is there any way I can get installed artifacts from the local repository 
> >> via antrun or pom.xml expressions?
> >>
> >> Thanks,
> >> Matthew
> >>
> >> -
> >> 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]

Re: [M2] Executing a single lifecycle phase

[Simon Kitching]

You can run a single goal with
  mvn plugin-name:goal-name

However if you've got a phase that has multiple goals bound to it, then
I don't know any way to run all those goals but not the goals bound to
earlier phases.

Regards,

Simon

On Thu, 2006-08-03 at 16:56 +0800, Maria Odea Ching wrote:
> Hi Mark,
> 
> I don't think there's a workaround for this. The previous life cycle 
> phases are always executed :)
> 
> Thanks,
> Odea
> 
> Mark Hansen wrote:
> 
> > When I do "mvn integration-test" - all the previous lifecycles phases 
> > (e.g., validate, compile, test, etc.) are executed first.  Is there a 
> > workaround that I can use to only run the integration-test lifecycle 
> > phase - without all the precursor phases getting invoked?
> >
> > Thanks,
> >
> > Mark
> >
> > -
> > 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]

RE: maven-surefire-plugin - turn off for "test", turn on for "integration-test"?

[Simon Kitching]

Hi Chris,

I don't think it's "bending" maven to run two lots of unit tests,
"normal" and "integration".

An  section defines invocations of the specified plugin *in
addition* to the standard one. If you want to skip the standard run, or
restrict the set of classes it runs, then do that inside the
 section of the plugin main block, not the 
section:

  
maven-surefire-plugin
...
true

  
 ...
 false

Because the additional execution inherits settings from the main one,
you need to reset skip to false in the nested definition. Using excludes
will work in the same manner.

Regards,

Simon

On Thu, 2006-07-27 at 15:52 -0700, Chris Wall wrote:
> Thanks Wendy.  Unfortunately svn.apache.org is timing out.  I did come
> across one of your earlier posts, so I now understand 
> better.  Base on one of your posts, I tried the following w/o success.
> 
> 
>  
>  
>surefire-unit
>test
>
>  test
>
>
>  
>**/*.java
>  
>  
>
>  
>  
>surefire-it
>integration-test
>
>  test
>
>
>  
>**/*.java
>  
>
>  
> 
> 
> I admit we're bending Maven a bit.  Actually, the entire module is a
> test project.  ;-)
> 
> -Chris
> 
> -Original Message-
> From: Wendy Smoak [mailto:[EMAIL PROTECTED] 
> Sent: July 27, 2006 5:23 PM
> To: Maven Users List
> Subject: Re: maven-surefire-plugin - turn off for "test", turn on for
> "integration-test"?
> 
> On 7/27/06, Chris Wall <[EMAIL PROTECTED]> wrote:
> 
> > I would like to turn off maven-surefire-plugin during the "test" phase
> > (so, no unit testing at all), and turn on maven-surefire-plugin for
> the
> > "integration-test".  Basically my source is a test webapp, and my
> tests
> > are integration tests.
> 
> The usual advice is to put your integration tests in a separate
> module, and bind executions of the compiler and surefire to the right
> phases.  Here's an example of that:
>  
> http://svn.apache.org/repos/asf/struts/struts1/trunk/integration/apps-it
> /pom.xml
> (There are much better examples in the Better Builds with Maven book
> from Mergere.)
> 
> Check the archives for some of my recent posts (2-3 months).  I got
> some help configuring the Shale Framework examples webapps, where we
> needed to keep the integration tests in the same module as the example
> app and its unit tests.
> 
> Here's one of those poms:
> http://svn.apache.org/repos/asf/shale/framework/trunk/shale-apps/shale-b
> lank/pom.xml
> 
> Along those lines, for your project, try letting Surefire run during
> 'test', but excluding all of the test classes.  Then bind a second
> execution of surefire to the integration-test phase.  (Based on the
> Shale example, you might have to explicitly  the test
> classes.)
> 
> HTH,


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: How to deselect classes while creating jar?

[Simon Kitching]

No, unfortunately the maven-jar-plugin for maven 2.x does not support
includes/excludes at the current time:
  http://jira.codehaus.org/browse/MJAR-30

You can of course control what goes into the jar by using
includes/excludes at the *compile* stage, if that's appropriate for your
project. If not, you might want to vote for that issue...

Regards,

Simon

On Thu, 2006-07-27 at 09:45 -0500, Chris Hilton wrote:
> I'm far from an expert, but I think you have to put your 
> elements in a separate  element, like:
> 
> 
>   
> 
> 
>   
>  
> 
> > -Original Message-
> > From: Abhijit Diwan [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, 27 July, 2006 00:28
> > To: users@maven.apache.org
> > Subject: How to deselect classes while creating jar?
> > 
> > Hi all
> > 
> >  
> > 
> >  I have maven 2.0 project which includes all the 
> > java classes for my project. Now I do not want to create 
> > single jar from the classes generated in the target 
> > directory. But there is no documentation on the maven jar 
> > plug-in site about how can I exclude the some of the classes 
> > from getting them in to the jar. I am using maven 2.0. Also 
> > there is lot of cyclic dependency in the classes so can not 
> > really separate the projects. 
> > 
> >  
> > 
> >  I feel there is no clear documentation about how 
> > can I skip some of the classes from getting in to the jar. I 
> > am using following profile like this and calling mvn jar:jar 
> > -PConnectorJar from the command line.
> > 
> >  
> > 
> > 
> > 
> > ConnectorJar
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > org.apache.maven.plugins
> > 
> > maven-compiler-plugin
> > 
> > 
> > 
> > 
> > 
> >  
> > com/tibco/ejb/common/*.java
> > 
> >  
> > com/tibco/ejb/connector/*.java
> > 
> >  
> > com/tibco/ejb/support/*.java
> > 
> >  
> > com/tibco/ejb/util/*.java
> > 
> >  
> > com/tibco/ejb/adapter/*.java
> > 
> >  
> > com/tibco/ejb/jca15/support/*.java
> > 
> >  
> > com/tibco/ejb/jca15/util/*.java
> > 
> >  
> > com/tibco/ejb/jca15/connector/**/*.java
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > org.apache.maven.plugins
> > 
> > maven-jar-plugin
> > 
> > 
> > 
> > AeConnector
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > AeConnectorJar
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> > Help on this will be really appreciated.
> > 
> >  
> > 
> > Thanks a lot
> > 
> > Abhijit
> > 
> >  
> > 
> > 
> 
> -
> 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: Expansion of maven variables

[Simon Kitching]

Hi Gilles,

Thanks for your comments.

On Mon, 2006-07-24 at 23:48 -0700, Gilles Scokart wrote:
> ${project.classpathElements} can be used when your parameter is a List . 
> Here you want to place it in a String.

True, and maybe that's the problem. The things that are working are all
of type String.

The data is magically managed via the declaration:
 /**
  * @parameter
  */
 private Properties systemProperties;

I believe that it is the plexus container that implements the necessary
"dependency injection" stuff to take the xml in the pom.xml file and map
it into a Properties object and assign it to systemProperties. Obviously
that code is buried deep down inside plexus where normal mortals can't
see.

A Properties object does implement Map and therefore potentially
supports objects, but the surefire code clearly doesn't support this
(and reasonably too):
   // Add all system properties configured by the user
   Iterator iter = systemProperties.keySet().iterator();
   while ( iter.hasNext() )
   {
 String key = (String) iter.next();
 String value = systemProperties.getProperty( key );
 System.setProperty( key, value );
   }

In my case, it would be ok for the classpath to be mapped from a List to
a string that the unit tests can parse; I therefore tried
  ${project.classpathElements.toString()}
but unfortunately that didn't work either. Oddly, neither did
  ${project.artifactId.substring(8)} 
when used in the properties section, though that expression certainly
does work in other places in the pom. Scary; I thought that this
variable handling/injection was being managed by Plexus and therefore
would work consistently everywhere but that doesn't seem to be the case.


If it's not going to be possible to map the classpath into a string so
it can be passed as a system property, can anyone else suggest a way for
the unit tests to obtain the surefire test-classpath? The unit tests are
explicitly run in a custom classloader to isolate them, so even if there
is some singleton method that the unit tests could call to obtain a
reference to the project object or the surefire plugin object, I expect
they wouldn't be able to see it.

I see that the existing code explicitly sets "basedir" and
"localRepository" system properties so unit tests can retrieve these.
Maybe this could be generalised..


> 
> Moreover, I think that the expension done into the pom, and the things done
> in the plugin is different. So, there is maybe some differences. 

Isn't it all done by Plexus?

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help!checkStyle [m2]

[Simon Kitching]

On Tue, 2006-07-25 at 05:29 +, narayan dhumale wrote:
>   
> Hi, I want to build the project with Checkstyle(where Java coding conventions 
> are applied) using maven 2.0.3.Please suggest me the wayout

You want the maven-checkstyle-plugin of course :-)
  http://maven.apache.org/plugins/maven-checkstyle-plugin/

Do you want a checkstyle *report* as part of your *project site*, or do
you want to fail the build if code doesn't pass checkstyle rules?

For reports, add the maven checkstyle plugin in the  section
of your pom.xml.

http://maven.apache.org/ref/current/maven-model/maven.html#class_reporting

I haven't done the build side myself, but here's an example from the
checkstyle plugin tests that I think is demonstrating this..
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin/src/test/plugin-configs/check-plugin-config.xml


Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Expansion of maven variables

[Simon Kitching]

Hi,

I'm confused by the availability of maven variables, in particular
${project.testClasspathElements}.

In a surefire config section, I've got this:


  
**/DumpProps.java
  
  

  test.finalName
  ${project.build.finalName}


  test.artifactId
  ${project.artifactId}


  test.version
  ${project.version}


   testclasspath
   ${project.classpathElements}

  


When run, I get this output:
 test.testclasspath:${project.testClasspathElements}
 test.classpath:${project.classpathElements}
 test.finalName:commons-logging-1.1.1
 test.builddir:${project.build.directory}
 test.artifactId:commons-logging
 test.version:1.1.1

There are clearly a number of variables that don't get expanded. However
all of these are listed as variables in the maven-surefire-plugin docs:
  http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
and of course this documentation is derived straight from the
annotations in the sourcecode:
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java


Can anyone explain what's happening here?

Just FYI, what I'm trying to do is pass ${project.testClasspathElements}
to the unit tests so that each test can control its own classpath,
ordering the jars however it needs using a custom classloader. As an
alternate approach, I hoped the assembly:unpack target could be used to
copy dependencies into a subdir of target, so I could hard-wire paths to
them in the sysprops but that isn't working as I do not want the jars
unpacked. Any suggestions for other approaches would be welcome.

Thanks,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven-jar-plugin: include/exclude functionality?

[Simon Kitching]

Hi,

I need to build 3 jars from the classes created by a module; a "full"
jar and two jars that contain subsets of the available classes.

Binding the jar:jar goal to the package phase using  causes
it to run fine, but I can't see any includes/excludes option for this
plugin in the documentation. I've tried it anyway, and while there are
no error messages any includes/excludes tags appear to be ignored. Am I
missing something?

If not, do I need to resort to binding the maven-assembly-plugin to the
package phase instead of the jar plugin? That looks possible, but not as
elegant..

Thanks,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Classpath for integration tests

[Simon Kitching]

Sorry, please ignore previous email. The problem is that my unit test is
explicitly looking for junit via the system classloader. Of course
surefire is loading junit via a custom classloader.

Regards,

Simon


On Tue, 2006-07-25 at 10:34 +1200, Simon Kitching wrote:
> Hi,
> 
> I'm trying to write a maven2 pom.xml for commons-logging. Running the
> unit tests is a little tricky, because there are lots of tests that
> explicitly configure their own classpath, using the artifacts created
> during the build process.
> 
> I've therefore got a set of unit tests that run in the normal "test"
> phase, selected by configuring the surefire plugin with .
> These work fine.
> 
> I've then used  to bind surefire to the "integration-test"
> phase as well. Unfortunately when surefire runs at this stage, junit
> does not appear to be on the classpath (NoClassDefFound occurs
> for ...). 
> 
> Any ideas how to get junit visible to the junit tests at
> integration-test phase?
> 
> I've tried marking the junit dependency as scope=test, scope=provided,
> and normal (no scope definition). No change.
> 
> I've tried setting surefire's "classpathElements" attribute in the
> execution section, but get "Cannot override read-only parameter:
> classpathElements in  goal: surefire:test".
> 
> Note also that I've defined the project dependencies in two profiles
> "build" and "use", as commons-logging must be built against all its
> dependencies, but they are all optional at runtime. It appears that
> maven2 doesn't put optional dependencies on the classpath at "compile"
> phase. I don't think this is related to the original problem though.
> 
> Attached is a cut-down version of the pom. Any advice welcomed.
> 
> Thanks,
> 
> Simon
> 
> 
> 
> 
> -
> 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]

Classpath for integration tests

[Simon Kitching]

Hi,

I'm trying to write a maven2 pom.xml for commons-logging. Running the
unit tests is a little tricky, because there are lots of tests that
explicitly configure their own classpath, using the artifacts created
during the build process.

I've therefore got a set of unit tests that run in the normal "test"
phase, selected by configuring the surefire plugin with .
These work fine.

I've then used  to bind surefire to the "integration-test"
phase as well. Unfortunately when surefire runs at this stage, junit
does not appear to be on the classpath (NoClassDefFound occurs
for ...). 

Any ideas how to get junit visible to the junit tests at
integration-test phase?

I've tried marking the junit dependency as scope=test, scope=provided,
and normal (no scope definition). No change.

I've tried setting surefire's "classpathElements" attribute in the
execution section, but get "Cannot override read-only parameter:
classpathElements in  goal: surefire:test".

Note also that I've defined the project dependencies in two profiles
"build" and "use", as commons-logging must be built against all its
dependencies, but they are all optional at runtime. It appears that
maven2 doesn't put optional dependencies on the classpath at "compile"
phase. I don't think this is related to the original problem though.

Attached is a cut-down version of the pom. Any advice welcomed.

Thanks,

Simon






jcl-pom.xml
Description: application/xml
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: log4j.properties expendable and ignored

[Simon Kitching]

Hi,

I've just gone through all the JIRA issues for SUREFIRE and can't see
any such issue. If it is true that src classes come before test classes
then I agree an issue should be raised. Ido, you could just add a test
which does 
   System.out.println(
 this.getClassLoader().getResource("log4j.properties").toString());
or similar to see which log4j properties file is seen first.

Another possibility for the log4j.properties being ignored is that there
is a log4j.xml file in the classpath somewhere. Config files in xml
format are used in preference to ones in properties format.

Regards,

Simon

On Sat, 2006-05-13 at 02:47 +0300, Arik Kfir wrote:
> I think there's a JIRA on the surefire plugin which gives precedence
> to the main classes over the test classes - hence the log4j.properties
> in src/main/resources is used before the src/test/resources's file is
> loaded.
> 
> 
> 
> On 5/12/06, Ido M. Tamir <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am using maven 2.0.4
> > I have log4j.properties file in src/test/resources and
> > src/main/resources.
> >
> > after compilation directory structure:
> >
> > -- test-classes
> > |   |-- hibernate.cfg.xml
> > |   |-- import.properties
> > |   |-- log4j.properties
> > |   `-- org
> >
> > The settings in this file are ignored in unit tests
> > and other settings (assembly...).
> > When I remove both files log4j doesn't even
> > complain.
> >
> > The log level always seems to be info.
> > This is also true for unit test run from
> > eclipse (I use mvn eclipse:eclipse)
> >
> > This is independent of having commons-logging
> > as a dependency or not.
> >
> > thank you very much for your suggestions
> > ido
> >
> >
> >
> >
> > -
> > 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: Dependency on war file in local repository.

[Simon Kitching]

On Fri, 2006-05-12 at 10:21 +0200, [EMAIL PROTECTED] wrote:
> Hello List,
> 
> I am a new user with Maven, so please excuse me if I am asking a trivial
> question.
> 
> My question is that I have a 3rd party war file, which I would like to
> extend with some additional functionality.   I read that if I in a war
> project, I specify dependency on another war, then the two will be merged.
>  However, I get stuck before that.
> 
> In my pom I have the following:
> ..
> 
>   net.sf.pebble
>   pebble
>   1.9
>   war
> 
> ..
> pebble is a 3rdparty war that I've installed into my local repository with:
> mvn install:install-file -Dfile=pebble.war -DgroupId=net.sf.pebble
> -DartifactId=pebble -Dversion=1.9 -Dpackaging=war
> 
> When I try to create the new war with the war:war goal, then I get the
> following:
> Downloading:
> http://repo1.maven.org/maven2/net/sf/pebble/pebble/1.9/pebble-1.9.pom
> [WARNING] Unable to get resource from repository central
> (http://repo1.maven.org/maven2)
> 
> However, this file should (and does) exist in the local repository. Is
> there some fundamental flaw in my understanding of Maven or am I just
> missing some step?

This is probably now the most frequently asked question on this list;
the maven docs really need to be updated to cover this.

As the message above shows, it is trying to download
  pebble-1.9.pom
ie a pom file, NOT the jarfile. This is just a warning that no pom file
can be located; everything will still work.

You can get rid of this by repeating the mvn install:install-file and
adding -DgeneratePom=true. See the email archives for this week for a
whole lot more info on this subject.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Downloading poms

[Simon Kitching]

On Tue, 2006-05-09 at 09:53 -0700, Tim McCune wrote:
> On Tue, 2006-05-09 at 22:25 +1200, Simon Kitching wrote:
> > Even if your process is just doing a copy, a pom file is a fairly simple
> > xml file. I'm sure your automated process could be enhanced to generate
> > one.
> 
> Thanks for the detailed response Simon.  Your answers make sense, but
> I'm still disappointed that Maven doesn't handle the missing pom
> situation better.  As you suggested, these auto-generated poms will
> basically be brain-dead, and will provide no useful information.  If
> that's the case, then why-oh-why does Maven require them at all?  I'd
> much rather spend a few minutes fixing Maven to make it stop trying to
> download pom files when it already has the jars, then write code to
> auto-generate useless poms, and make sure that it gets plugged in
> everywhere necessary.  I'll probably do this and submit it as a patch,
> unless someone can explain to me the virtues of having all of these
> empty poms floating around.

Well, maven will need some way to figure out whether it has tried to
download or not. As I described earlier, for some jars such as Sun's
stuff it *is* desirable to download a pom even when the jar is available
locally.

It does seem reasonable for Maven to remember when it tried to download,
successfully contacted all known remote repositories, but found no pom.
In this case it could skip later attempts. Of course that assumes that
no-one uploads a pom later, but that's not too likely to happen. So how
could maven "remember" not to download more poms? Well, possibly by
creating the pom.xml file itself...

I think a nicer solution, though, would be a plugin,
"maven-pomgenerator-plugin". If a user is sick of seeing failed pom
access attempts, they could just run:
  maven pomgenerator:generate-all
which would cause the plugin to walk the repository tree and generate a
"brain-dead" pom for every jar that doesn't have one.

Because it needs to be explicitly run, the user has more control I
think. It's also far easier to implement that way, and I think more in
the spirit of Maven.

Note that I've never written a maven plugin myself; I'm only presuming
it's possible to implement what I've described.

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problems with javax.sql:jbdc-sqlext download

[Simon Kitching]

On Wed, 2006-05-10 at 11:39 -0400, McGarr, Joseph M wrote:
> All:
> 
>  
> 
> I cannot download the javax.sql:jdbc-sqlext:jar:2.0 from the ibiblio
> repository.  it appears that this jar was never added correctly, only
> the sources, the pom and their checksum files exist in the repository,
> but no jar or maven-meta.xml file.  How do we get a copy of these files
> up?

I think what you are seeing is correct. 

Because of Sun's license conditions, many of their jarfiles cannot be
redistributed; they must be downloaded from Sun (including agreeing to
the license etc).

However pom.xml files *can* be uploaded, because they are not created by
Sun. Even without the jars, they are useful as they define the
dependencies etc.

So download the jarfile from sun, and install to your local repository
(or a repository hosted by your "organisation"). When you run maven, the
matching pom will be downloaded and all will be well.

I don't know why the sources jar is there. I have heard that Sun has
started using a new license that allows source redistribution but not
binary; maybe this code falls under that new license (NB: just a guess).

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] internal repository with jars but no pom

[Simon Kitching]

On Tue, 2006-05-09 at 00:48 -0700, barth wrote:
> I am stupid... and not patient enough !!!
> After the hundreds of "unable to get resource..." for the pom files, it
> downloads directly the jars. Therefore I have just had to wait a bit. 

And if you really can't be bothered to install pom files into your repo
via one of the ways discussed earlier in this thread, then you can
always use
 mvn -o ...
or put 
  true
in your settings.xml file.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Downloading poms

[Simon Kitching]

On Mon, 2006-05-08 at 16:08 -0400, Alexandre Poitras wrote:
> If I remember correctly, Maven 2 was able to work without pom in the past
> but in the end there were so many jars coming without pom that they decided
> to remove the option. But I could be wrong.

I'm pretty sure maven2 works fine without pom files. However it does
waste time by trying to find the pom each time, and generates warning
messages about not being able to find them.

Installing a basic pom for each jar is definitely the easiest and best
solution.

Otherwise, it's probably fairly simple to create a script that walks a
repo tree and generates poms for all jars without one. The path to the
jar has enough info to generate a basic pom I think (group, artifact,
version).

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Downloading poms

[Simon Kitching]

On Mon, 2006-05-08 at 11:50 -0700, Tim McCune wrote:
> On Mon, 2006-05-08 at 13:36 -0500, Wayne Fay wrote:
> > When you installed those dependencies in your local repo, did you use
> > -DgeneratePom=true   ?
> > 
> > If not, reinstall the 3rd party artifacts and use that parameter so
> > poms are created, to avoid this "downloading poms from central" thing
> > in the future.
> 
> Thanks for the reply Wayne.  Not quite sure what you're referring to.
> The jars that get installed in my local repo are put there 1 of 2 ways.
> Either:
> 1) Checked into a subversion module, which copies them to a web server
> on commit.
> 2) Placed on the web server by Continuum after building the project with
> Maven 1.
> 
> For option 1, it sounds like you're suggesting that there's a way to get
> Maven to generate a pom for the jar file?  If so, could you elaborate?

Maven always *wants* a pom, as that makes it possible for maven to
automatically handle transitive dependencies. If there is one in your
repo, it will use it and NOT go to the central repository. If there
isn't one locally, it will of course try to get one remotely. If it
can't find one anywhere, it still continues to work but as you've
noticed there is a performance hit and warning messages due to the
failed attempts to find a pom.

As Wayne said, ensuring your repo has a pom for each installed jar
solves this problem.

Files can be installed into a repository using the command
  mvn install:install-file -DartifactID=.. -DgroupId=.. etc
By default, the file is just copied into the repo; no pom.xml is
created. However the params carry enough info to generate a primitive
pom.xml file; adding -DgeneratePom=true to the arguments will do this.
The generated file of course has no info on the dependencies of the jar
you've just installed.

If you simply use a copy command to install the jars into the right repo
directories instead of mvn install:install-file, then that's fine too.
Creating the appropriate primitive pom file is easy by hand or could be
automated I'm sure.

So why isn't -DgeneratePom=true the default? Because there are some
cases where the central maven repo (on ibiblio) isn't allowed to host
the jar for legal reasons. However it *is* of course legal for a pom.xml
(including dependency info) to be in the repo. In this case you really
want to install the jar locally but not create a pom; maven will then
download the correct pom.xml from the central repo.

> For option 2, Maven 2 isn't involved at all, and it's an automated
> process, so I don't think that it's feasible at all to get a pom
> generated for these jars.

If your automated process is using "mvn install:install-file" then just
add the -DgeneratePom=true option.

Even if your process is just doing a copy, a pom file is a fairly simple
xml file. I'm sure your automated process could be enhanced to generate
one.

Cheers,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Odd Compilation Issue

[Simon Kitching]

On Fri, 2006-05-05 at 14:20 -0700, Sean McNamara wrote:
> I'm having a VERY odd compilation problem and am at a loss for why it would 
> occur.  We're in the process of moving from Maven v1.1 to Maven 2.  We ported 
> the project.xml files over to pom.xml, and succeeded in getting the build 
> going.  Unfortunately, the new archive was failing to run.
> 
> After chasing my tail for the last week, I took a look at the classfiles that 
> were giving us a problem in a hex editor, and see that the actual classfiles 
> differ in terms of the major and minor numbers in the classfile.
> 
> I only have a single JVM installed on this machine, so I'm pretty confident 
> the same one is being used in both compiles.
> 
> Does anyone have the slightest idea how this might be possible?

Java compilers are capable of generating output in older formats.

In m2, I think the maven-compiler-plugin defaults to 
  -target 1.3
ie generates output in a format compatible with 1.3 JVMs. Different
-target options will indeed cause different major/minor numbers in the
generated .class files.

Try setting source/target to your desired values, using the syntax in
the compiler plugin docs:
  http://maven.apache.org/plugins/maven-compiler-plugin/howto.html

I don't understand why the output would "fail to run", though, as the
output cannot be newer than the JDK version you've got installed and you
say you have only one JDK on your machine.

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Issues downloading from repos

[Simon Kitching]

Hi,

You can also put
  true
in your settings.xml file to disable remote access permanently, once
you've managed to download all the necessary dependencies.

http://maven.apache.org/ref/current/maven-settings/settings.html

Regards,

Simon

On Wed, 2006-05-03 at 15:21 +0200, Kees de Kooter wrote:
> Yes. ibiblio (== repo1) is a very busy site.
> 
> Once you have built your project succesfully once all dependencies are
> in your local repository. You can then run your build offline with the
> -o switch.
> 
> On 5/3/06, Douglas WF Acheson <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> >   Being new to Maven2 I am not sure if this is really an issue.  I am
> > having problems when downloading plugins and dependencies from various
> > repos (ibiblio, codehause, repo1).  It takes forever to download either
> > the pom or the jar files.  And quite often if fails.
> >
> >   When it fails, I have to start the process over again. And it may
> > download the required artifact or it may not.  To do a compile, I will
> > have run the maven goal quite a few times before it actually does the
> > compile.
> >
> >   Is anyone else experiencing this problem?
> >
> > --
> > Regards,
> > Douglas WF Acheson
> >
> >
> > -
> > 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]

Re: Artifacts reference in Maven2

[Simon Kitching]

On Wed, 2006-05-03 at 08:31 +0200, Sharma, Jaikumar wrote:
> Dear Maven Users,
>  
> Can I use third party libraries (required by build process to compile / test
> sources etc.) which are located in application installed location in the
> filesystem without installing them into local repository ? 
>  
> As far as Maven documentation is concerned it describes two ways : One by
> installing the artifact into local repository and other by specifying the
> system and  in the
>   section (use of this is discouraged as mentioned
> by Maven docs).
> http://maven.apache.org/ref/current/maven-model/maven.html
>  
>  
> I want most of the artifacts to be referred by the build process at their
> original location and not by moving everything to repository.
>  
> Is there a third way exists in maven 2 to refer the artifacts in the build
> process ? Might be the case that I have not come across to that so far.
>  

The third option is to set up your own repository. This is very easy to
do; configure an http server which serves files from a directory with a
standard maven repository layout. Uploading files to such a system is
probably easiest by network-mounting the directory the http server is
serving files from. This tree can even be handily initialised by copying
your local repository dir (just remove any metadata files). Once your
repo is set up, just define it in the pom.

I gues a custom plugin could be written to add jars from other sources,
but I'm not aware of any existing plugin that does this, probably
because the built-in maven options are fine.

There are no other options I'm aware of. Maven doesn't support just
pointing at arbitrary directories full of jars; it's considered bad
practice as dependency info can't be properly managed. If dependency
management isn't needed, then perhaps Ant is the best tool to use.

Regards,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] Is there any way to override the default filter pattern for resources?

[Simon Kitching]

On Sat, 2006-04-29 at 16:09 -0400, Colin Sampaleanu wrote:
> Hi,
> 
> When turning on filtering for resources in Maven2, is there any way to 
> override the default filter string pattern of '${token}'?  I can't find 
> any mention of any way to customize this, in any docs.
> 
> The use of ${token} as a token is IMHO a really bad choice, given the 
> fact that it's such a common token replacement syntax in various page 
> templating technologies like JSPs. These are exactly the kinds of files 
> likely to be copied around as resources, leading to all sorts of 
> potential conflicts in filter instances meant to be replaced by Maven, 
> and instances meant for the JSP engine.

Well, I believe that any tokens not recognised will be left unchanged.
So if you ensure non-conflicting names are used for those tokens you
want to substitute during builds, eg
  ${buildtime.username}
instead of
  ${username}
won't this achieve what you want?

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Explain multi-module support in M2

[Simon Kitching]

Hi Clifton,

Note that there are two different concepts here.

(a) A "parent pom" is a pom whose attributes are inherited by any pom
whose  tag points at it.

(b) A "module pom" uses  tags to point at directories containing
pom files. Whenever the "module pom" is specified, the phase/goal is
executed for that pom AND every pom pointed to by it. The module poms
are first inspected to determine from their dependencies the correct
order to invoke them; the maven component that generates the
correctly-ordered set of modules is referred to as a "reactor".
[NB: I just made up the term "module pom"; maybe there's an official
term].

Often a single file fills both roles, but they can be separate.

When a pom points at a parent, it can specify a (groupId,artifactId) in
which case the parent pom is fetched from the maven repository. This
allows a module to be built even when the "parent" has not been checked
out locally; very useful. A pom can also specify a relativePath; if the
specified file actually exists locally it is used in preference. This
makes development easier as it's possible for changes to the parent pom
to take effect without running "mvn install" on it. There are no limits
at all imposed on your directory here; a child can point to any parent
it wants.

A  tag simply specifies a directory. Paths like
"widgets/widget1" are fine. I suspect that "../widget1" would also work
but haven't tried it. Assuming it does, there are no limitations on the
layout.

There is no mechanism that ensures that when you execute a goal in
module Z, its dependencies are all rebuilt; the latest versions of all
dependencies are just fetched from repositories. To rebuild everything,
you execute a phase/target using the "module pom".

Regards,

Simon

On Thu, 2006-04-27 at 14:15 -0400, Clifton Craig wrote:
> Hello all,
> 
> I'm relatively new to Maven2 and I'd like somebody to explain the 
> multi-module 
> support in a little more detail. We have some projects that we're managing 
> with M2. I'm not sure that I want to use multi-module support because it 
> seems a little restrictive as explained on the site. However, I'm afraid that 
> I may need some of the features from mult-module support. Let me clarify. 
> Take the following example: Projects A, B, C, and D. B, C, and D all depend 
> on A. C and D depend on B. The one problem (due to my lack of understanding) 
> I have is that for multi-module support to work, as I understand it, I would 
> need to reflect the module dependencies in the directory structure of the 
> modules. This means a module folder would need to sit atop of its dependency 
> module folders. In my example there is no clean way (short of using 
> replicating modules or icky non-x-platform symbolic links) to acheive the 
> relationship in the directory structure. So it makes better sense to layout 
> all modules as peers including parent modules and folders with parent pom 
> files. I'm not sure if this is supported or I'm not understanding the 
> workings correctly. 
> 
> The other problem I have is that if my prior explanation is not accurate how 
> would we make the association evident in child modules to their parents? In 
> other words, assume I have all modules A-D laid out as peers on the 
> filesystem. Also assume that there is a global module, E, that contains 
> settings that are inherited by the others A-D. (E is also a peer.) If I'm 
> working in the folder for B and decide to run "mvn test" or "mvn deploy", how 
> then does it know to look into the peer folder for E for inherited settings? 
> It seems to me that either some sort of reference need to be made to the 
> location of E or E would need to be installed first before testing or 
> deploying B. I'm sure I have some things misunderstood but could somebody 
> clear things up for me?
> 
> --- 
> Clifton C. Craig, Software Engineer
> Intelligent Computer Systems -  A Division of GBG
> [EMAIL PROTECTED]
> [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]

Re: New to Maven

[Simon Kitching]

On Wed, 2006-04-26 at 09:59 -0700, ajayasahoo wrote:
> I am new to Maven.
> 
> I have downloaded maven-2.0.4 and following the Maven Getting Started Guide.
> 
> I am under How do I make my first Maven project? and issue the following
> command
> 
> mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app
> 
> I get this error:
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] The plugin 'org.apache.maven.plugins:maven-help-plugin' does not
> exist or no valid version could be found.

Try "mvn -X ." to show debug output.

I expect that you're running behind some kind of firewall that is
preventing maven from downloading the plugins it needs. The maven
download is just the core of maven; many of the plugins it needs to do
its job are downloaded on demand.

If a firewall is the issue, see the documentation on the maven site re
defining proxy settings in a settings.xml file.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: issue with mvn clean install

[Simon Kitching]

Yep, that looks like the cause to me. if ${basedir} is mapping to ".",
then when maven tries to delete the "output directory" it would end up
deleting the "Project A" dir, just as shown.

Try removing the outputDirectory elemnt from the pom (so it defaults to
its normal value).

Cheers,

Simon

On Thu, 2006-04-27 at 11:12 +0200, Tom Joad wrote:
> Why do you have to set explicitly ${basedir} On project A pom.xml for
> different location.
> Try to give relative path so without ${basedir}
> Tom.
> 
> 2006/4/27, RobJac <[EMAIL PROTECTED]>:
> >
> > Yes I do. This is how my Project A pom.xml looks like
> >
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> >   4.0.0
> >   Project A
> >   Project A
> >   jar
> >   1.0
> >   Maven Quick Start Archetype
> >   
> > Main
> > Main
> > 1.0
> >   
> >   
> > 
> >   antlr
> >   antlr
> >   2.7.5H3
> >   provided
> > 
> >
> >   
> >   
> > ${basedir}
> > classes
> > ${project.artifactId}
> > test-classes
> > src
> > test
> > 
> >   
> > ${basedir}/resources
> >   
> > 
> > src
> > false
> > 
> >   **/*.java
> > 
> >   
> >
> > 
> > 
> >   
> > test
> >   
> > 
> > 
> > 
> >   org.apache.maven.plugins
> >   maven-compiler-plugin
> > 
> >   1.5
> >   1.5
> > 
> >
> > 
> >   
> >
> >   
> > target/site
> >   
> > 
> > --
> > View this message in context: 
> > http://www.nabble.com/issue-with-mvn-clean-install-t1516559.html#a4117154
> > Sent from the Maven - Users forum at Nabble.com.
> >
> >
> > -
> > 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]

Re: [ANN] Free Maven 2 Book now available: Better Builds with Maven

[Simon Kitching]

On Thu, 2006-04-27 at 17:52 +0900, Youngho Cho wrote:
> Hello 
> 
> When I tried, I got
> 'Not a Valid email address, please try again.'
> popup message 
> 
> How can I download it ?

Yep, looks like mergere's download page is brain-dead.
The address [EMAIL PROTECTED] works fine.
The address [EMAIL PROTECTED] gives "invalid address".

So it looks to me like the page can't handle two dots in the address. I
suggest you use a yahoo.com or hotmail.com address, or wait until
someone at mergere fixes this (I'm sure it won't be long...)

Cheers,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: issue with mvn clean install

[Simon Kitching]

This is very odd. Normally, "mvn clean" would simply run "mvn clean" in
each of the defined modules. That's certainly what it does for me.

The child modules would then respond by (normally) deleting the "target"
directory, to get rid of any old .class directories etc.

What does your project A's pom.xml look like?

Regards,

Simon


On Thu, 2006-04-27 at 01:12 -0700, RobJac wrote:
> I have a maven project folder structure as shown below
> 
> Main
>   pom.xml
>   
>   Project A
>   pom.xml
>   
>   Project B
> pom.xml
> 
>   Project C
> pom.xml
> 
>   Project D
> pom.xml
> 
> I am trying to build and install multiple projects. So in the Main folder if
> i run mvn clean install. Its trying to delete the folder Project A and then
> trying to install Project A and fails saying that the Project A pom xml is
> not found. I dont really understand what is the point in doing mvn clean
> install instead mvn install works fine for me.
> 
> Pls see below the exception i get
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO]   Unnamed - Main:Main:pom:1.0
> [INFO]   Maven Quick Start Archetype
> [INFO]   Maven Quick Start Archetype
> [INFO]   Maven Quick Start Archetype
> [INFO]   Maven Quick Start Archetype
> [INFO]
> -
> ---
> [INFO] Building Unnamed - Main:Main:pom:1.0
> [INFO]task-segment: [clean, install]
> [INFO]
> -
> ---
> [INFO] [clean:clean]
> [INFO] Deleting directory C:\Main\target
> [INFO] Deleting directory C:\Main\target\classes
> [INFO] Deleting directory C:\Main\target\test-classes
> [INFO] [install:install]
> [INFO] Installing C:\Main\pom.xml to C:\Maven\remote\repository\Main\Main
> \1.0\Main-1.0.pom
> [INFO]
> -
> ---
> [INFO] Building Maven Quick Start Archetype
> [INFO]task-segment: [clean, install]
> [INFO]
> -
> ---
> [INFO] [clean:clean]
> [INFO] Deleting directory C:\Main\Project A
> [INFO] Deleting directory C:\Main\Project A\classes
> [INFO] Deleting directory C:\Main\Project A\test-classes
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] No sources to compile
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
> [INFO] [jar:jar]
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar: C:\Main\Project A\Project A.jar
> [INFO] [install:install]
> [INFO] Installing C:\Main\Project A\Project A.jar to C:\Maven\r
> emote\repository\Project A\Project A\1.0\Project A-1.0.jar
> [INFO]
> -
> ---
> [ERROR] BUILD ERROR
> [INFO]
> -
> ---
> [INFO] Error installing artifact's metadata: Error installing metadata:
> Error re
> writing POM
> 
> C:\Main\Project A\pom.xml (The system cannot find the file specified)
> [INFO]
> -
> ---
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> -
> ---
> [INFO] Total time: 4 seconds
> [INFO] Finished at: Thu Apr 27 08:53:39 BST 2006
> [INFO] Final Memory: 4M/8M
> [INFO]
> -
> ---
> 
> This is how the pom xml of the Main folder looks like
> 
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>   Main
>   Main
>   pom
>   1.0
>   
>   Project A
>   Project B< 
>   Project C<
>   Project D<
>   
> 
> 
> Am I missing something here?
> --
> View this message in context: 
> http://www.nabble.com/issue-with-mvn-clean-install-t1516559.html#a4116302
> Sent from the Maven - Users forum at Nabble.com.
> 
> 
> -
> 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: [M204] Can't replace propertise in settings.xml

[Simon Kitching]

Hi Michael,

Is your profile "user-properties" actually *active*?
  mvn help:active-profiles

There are many ways of activating a profile (as described in the maven
docs). The most direct one is:
  mvn -P user-properties ...

Regards,

Simon

On Wed, 2006-04-26 at 10:52 +0200, [EMAIL PROTECTED] wrote:
> Hi,
> I was trying to replace properties in the settings.xml file as described
> in the (really nice) book of mergere, p 205. Unfortunately this doesn't seem
> to work for me.
> The properties don't get replaced. In the ssh log i see that the user 
> ${website.username}
> tried to log in.
> Can anybody tell my why this doesn't work?
> 
> In MAVEN_HOME\conf\settings.xml i have this:
> 
>   
> 
>   website
>   ${website.username}
>   ${website.password}
> 
>   
>   
> user-properties
>   
> 
> 
> In USER_HOME\.m2\settings.xml I have this:
> 
>   
> 
>   
> 
> mylogin
> mypassword
>   
>   user-properties
> 
>   
> 
> 
> The output of "mvn help:effective-settings" can be seen below:
> 
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO] 
> 
> [INFO] Building Patrec Konverter
> [INFO]task-segment: [help:effective-settings]
> [INFO] 
> 
> [INFO] [help:effective-settings]
> [INFO] 
> Effective settings:
> 
> 
>   C:\Dokumente und 
> Einstellungen\mim.HPLUSDOM\.m2\repository
>   
> 
>   ${website.username}
>   ${website.password}
>   website
> 
>   
>   
> 
>   
> mylogin
> mypassword
>   
>   user-properties
> 
>   
>   
> user-properties
>   
> 
> 
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESSFUL
> [INFO] 
> 
> [INFO] Total time: 1 second
> [INFO] Finished at: Wed Apr 26 10:49:00 CEST 2006
> [INFO] Final Memory: 2M/5M
> [INFO] 
> 
> 
> 
> -
> 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: Getting root parent POM artifactid

[Simon Kitching]

Hi,

I believe that it is not possible to access artifactId/version/etc from
parent poms. However it is possible to define properties in the parent
pom which are accessable from the dependent projects.

Cheers,

Simon


On Tue, 2006-04-25 at 15:14 +0400, javed mandary wrote:
> ${project.artifactId} and ${project.version} just retrieves value for MODULE
> C not for the root POM unfortunately
> 
> On 4/25/06, Sharma, Jaikumar <[EMAIL PROTECTED]> wrote:
> >
> > It is ${project.artifactId} and ${project.version}, as far as know.
> >
> > -Original Message-
> > From: javed mandary [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April 25, 2006 4:18 PM
> > To: Maven Users List
> > Subject: Getting root parent POM artifactid
> >
> >
> > Hi,
> > is there any properties value that returns the top Parent POM's
> > artifact id and version number.
> >
> > Say i have a structure as follows:
> >
> > root POM
> >   |
> >   |--module A POM
> >   |
> >   |-module B POM
> > |
> > |--module C POM
> >
> >
> >
> > Is there a way to retrieve the artifactId and version number of top root
> > POM from module C POM ?
> >
> > cheers,
> > Javed
> > - - - - - - - DISCLAIMER- - - - - - - -
> > Unless indicated otherwise, the information contained in this message is
> > privileged and confidential, and is intended only for the use of the
> > addressee(s) named above and others who have been specifically authorized
> > to
> > receive it. If you are not the intended recipient, you are hereby notified
> > that any dissemination, distribution or copying of this message and/or
> > attachments is strictly prohibited. The company accepts no liability for
> > any
> > damage caused by any virus transmitted by this email. Furthermore, the
> > company does not warrant a proper and complete transmission of this
> > information, nor does it accept liability for any delays. If you have
> > received this message in error, please contact the sender and delete the
> > message. Thank you.
> >
> >


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dependencies Options

[Simon Kitching]

On Mon, 2006-04-24 at 21:25 -0400, Alexandre Poitras wrote:
> On 4/24/06, Brandon Goodin <[EMAIL PROTECTED]> wrote:
> > "tons of advantages" - please quantify this.
> 
> Well distributing internal corporation dependencies and managing the
> version, especially nightly build is way easier using Maven repository
> capabilities. Managing your project dependencies version is also
> really easier (especially conflicts and snapshots).

I would disagree. Managing dependencies is really easy when you've
checked jars into a directory - the jars used are the ones in that dir,
and nothing else.

Of course this does have the disadvantages listed in my mail (more repo
space needed, more bandwidth).

> 
> All the Maven generated reports also work better with regular
> dependencies because they can find some metadatas to work with.

true.

> 
> >
> > Personally, I find the repository to be a "nice" piece of Maven. But,
> > I don't see it as a cardinal sin to actually distribute libraries in
> > your project. If you follow the libary naming convention then who
> > cares?
> >
> > Personally, what i find annoying are the copious additional, needless,
> > and redundant dependencies that i have to download because of the
> > dependencies defined in the pom of a jar that i need to download.
> 
> Nothing the exclude tag can't fix.

That can be quite clumsy to use, though. Sometimes half-a-dozen libs
need to be excluded, at which point the pom becomes hard to read.

> 
> > I also find it annoying to have to manually install several small
> > libraries to my local repo cuz i can't distribute them as a result of
> > licensing. It is additionally annoying to have to setup a jar
> > repository that will be used for jars that will be needed that can
> > only be distributed privately. All of this... vs. me just referencing
> > them in my source tree?
> >
> 
> You are making this sound like it is a lot of work. Manually
> installing files on a corporate repository using install:install-file
> usually doesn't take more time then checking them inside SVN. A maven
> repository is basically a Jar versionning systems.

[as noted in your followup, you meant deploy:deploy-file]

That's assuming that a corporate repo exists and that it has upload
support available.

> 
> > I like Maven a lot and really enjoy the standard project layout
> > features and plugins that are provided. But, the jar repository has
> > caused me more time and less efficiency. However, i do like ibiblio
> > for a single one stop shop for grabbing jars i need... to drop in my
> > source tree ;-)
> >
> > I like it when people can check out my source from SVN and simply
> > build. This is possible when i place them in SVN. Heck, I can even
> > check Sun Jars into my SVN repo! ;)
> 
> If you have a remote Maven repository on the same server as your SVN
> repo, I really don't see the difference.

True, as long as:
(a) your svn server is already running behind a webserver, so the maven
repo can easily be set up,
(b) there is some upload support for that server,
(c) there is some way of ensuring that jars always come from this repo,
and never from ibiblio (this is the hardest bit in my experience)

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [M2] - Third party artifact installation / parse error in POM

[Simon Kitching]

On Tue, 2006-04-25 at 08:54 +0200, Sharma, Jaikumar wrote:
> Thanks Tim for useful tip, I installed the thirdparty artifact, but did
> not use the option as you mentioned -- (-DgeneratePom=true). I would do
> this and let you know the results.

Note: there are some jars (in particular, Sun stuff like
javax.transaction) for which there is a pom in the ibiblio repository,
but not the jar, for legal reasons.

For these jars, you don't want to specify -DpomFile or -DgeneratePom;
just install the jar and the pom will be downloaded (with all the right
info). At least I think that's how it works.

> 
> In the settings.xml, I have specified the localRepository pointing to
> local filesystem, but file:// -- protocol has been specified. Might be
> that because of the first problems, further stacktrace is getting
> generated. I would try and see the results.

Are you talking about the *local* repository (ie cache typically in
~/.m2/repository), or a remote repository that happens to be hosted by
you? If the latter, I've been unable to get file:// urls working; if you
do, please let me know!

Regards,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dependencies Options

[Simon Kitching]

Hi,

I agree with much of what Brandon is saying.

For *open source* projects, Maven's repository is really useful; the
minor inconveniences are worth living with. In particular, such projects
need to conserve disk space and network bandwidth; checking in jars for
each project is therefore a bad idea. Brandon: imagine if Apache
projects used the "check jars in with project" approach; the disk space
needed would multiply 100-fold, with the same jar checked in multiple
times under different projects. It also means that those files are all
downloaded from the apache site, not ibiblio. And it means that users
(who may be on dialup connections) end up downloading the same jars
multiple times even when they already have those jars on their local PC.

For *internal* projects, however, having local jars can be very useful.
Bandwidth is less of an issue; simplicity and reproducable builds are
more important. And as several people have noted on this list (and I've
found from experience too) preventing maven from fetching stuff from
repositories beyond your control is currently *really hard*.

I think it would be really nice if repositories could have a
false tag; a "non-remote" repo (using any access
protocol) would be used when offline mode is used. People could then
check a complete maven repository into their project if they wish, and
use a repository declaration with url "file://...", remote set to false,
and offline set to true. This wouldn't be recommended for sites that
host large numbers of projects, as disk-space and bandwidth issues would
cause problems, but it's then easy to set up self-contained builds for
smaller sites. It's not *quite* as simple to use as simply checking in a
directory of jars and pointing to that dir, but it's close - while still
supporting much of maven's standard dependency support. Hmm..could the
same effect be achieved by checking in an "settings.xml" with
localRepository pointing to a checked-in dir, and running maven with
"mvn -s ./settings.xml"?

Brandon: Note that when using system, transitive
dependencies aren't supported. It's really meant only for pointing at
files like "rt.jar" from a locally-installed jdk. That doesn't mean you
can't use it for the purpose you want, but that's not its intent.

Cheers,

Simon

On Mon, 2006-04-24 at 16:13 -0600, Brandon Goodin wrote:
> Hey Wayne, I'm sorry if my email tone sounds aggressive... i really am
> not trying to come off that way. So please accept my comments purely
> as an exercise in conversation.
> 
> I totally understand the intellectual property that rights that Sun
> attaches to their jars. I fully respect them. I'm just trying to
> understand why so much emphasis is placed on the centralized jar repo.
> There were plenty of other concerns besides the sun jars that i cited.
> I'm just speaking more from my needs. The repo is cool. But, I see an
> equally acceptable approach of having jars that you check into your
> source code repo. I guess I'm trying more to understand why there is
> such an emphasis on central repo over simply presenting the ability to
> use either/or.
> 
> As an additional note, the centralized repo is only as good as those
> willing to post to it. I've run into the problem that the latest and
> greatest are not always on ibiblio. I've also ran into the problem
> that there are sometimes version gaps. Also, I've seen where there are
> the same jars under different (but similar) group ids. I know i can
> setup a local repo for jars. But, then i find myself wondering why.
> Especially when i already have a versioning repository... SVN.
> 
> Many thanks for your time and responses,
> Brandon
> 
> 
> 
> On 4/24/06, Wayne Fay <[EMAIL PROTECTED]> wrote:
> > That should be "Checking Sun Jars into your SVN repo". Obviously
> > anyone is allowed to download the Sun Jars and install them into their
> > own local Maven repo, or anything else permitted under the Sun BCL
> > terms.
> >
> > Checking the jars into a publicly available distribution service ie
> > Sourceforge CVS/SVN etc is unfortunately not allowed by Sun's
> > licensing.
> >
> > You can go to Sun.com and read the specifics of the BCL if you want,
> > to see what specifically is permitted and what is not.
> >
> > Wayne
> >
> > On 4/24/06, Wayne Fay <[EMAIL PROTECTED]> wrote:
> > > Checking Sun Jars into your repo is a violation of the Sun Binary
> > > Compatibility License which you agreed to when you downloaded the
> > > file. (Assuming the file was downloaded from Sun under the Sun BCL
> > > terms, which most files on Sun.com require you to accept prior to
> > > downloading.)
> > >
> > > I doubt Sun will chase you down and prosecute you, but realize that
> > > some of us actually care about respecting intellectual property and
> > > license requirements. Complaining about the way these Sun Jars are
> > > handled to the Maven User list is really the wrong place -- complain
> > > directly to Sun, ask them to modify the distribution terms of their
> > > li

Re: m2 Can a web project depend on source code from other web project

[Simon Kitching]

On Sat, 2006-04-22 at 03:25 -0500, Gautham Pamu wrote:
> Hi Everyone,
> 
> I have strange scenario. I have two web projects, one web project A is
> accesing code from another web project B. Since
> RAD allows it, the developer add the dependency on another web project in
> RAD.
> 
> Even though I defined the dependency in pom.xml between the web projects,
> the second web project  A is not able
> to see the classes from ther other webproject. How should I define the
> dependency for this project


In order for project A to have a dependency on a jar, it needs to be
able to point to that jar in the local maven repository. However when a
"war" project is installed into a repository, it is the .war that is
installed; there is therefore nothing suitable for A to point to.

I guess it's possible to use "brute force". The maven-assembly-plugin
allows you to build a jarfile containing whatever you want from the
project. And the maven-install-plugin allows you to install whatever
artifacts you want into the local repository. You could therefore attach
a custom assembly definition to the "assemble" phase, and a custom
install definition to the "install" phase, using  tags.

It's quite common to generate "variants" of projects (sorry, there's
some maven terminology for this which I can't remember for the moment).
For example, a jar project can build foo.jar plus variants like
foo-src.jar, foo-jdk14.jar, etc. Anyone know if this mechanism could be
used to add a jarfile of the classes for a webapp (or some subset of
them) as one of its generated artifacts? Or is it done just like the
approach described above?

Otherwise I think you *have* to split up project B into two parts: a
"jar" project and a "war" project. Both A and b-war can then depend on
B-jar. It's certainly the cleanest solution.

NB: I'm no maven guru; any or all of the above could be wrong :-)

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: modules

[Simon Kitching]

On Sat, 2006-04-22 at 15:32 +1000, Torsten Curdt wrote:
> I am currently playing with converting commons-jci to maven2 and
> while doing that I would like to separate out the individual
> compiler implementations.
> 
> So I delegated the implementations into modules. But as soon
> as defined them in the pom I need to switch to packaging of
> type "pom" instead of "jar" ...and my core build gets ignored.
> 
> Do I really have to put the classes into a core module?

Yes I believe so. A pom that defines  entries cannot also build
code; as you've discovered packaging must be "pom" for that file.

If the "core" code has a *compile-time* dependency on all of the
implementations, then it declares dependencies on all the various
compiler implementations. This module can be responsible for building
the distribution bundles (tar/zip/etc) as it has all the dependency info
available.

If the "core" code however simply *allows* compiler implementations to
be plugged in, but doesn't depend on any of them, I think you can
declare the dependencies with true, and still be
able to use that module to build the distribution bundles. If that
doesn't work (or you don't like it) then you can leave out any
dependencies from core->compiler modules, and add a separate "dist"
module that depends on core + all compiler modules, and whose purpose is
just to build the tar/gzip/etc files.

The separation of core and "top-level pom" seems nice to me. 

NB: I've been using maven a while, but am no guru. All the above is
subject to correction.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SVN paths when adding an m2 pom with module declarations

[Simon Kitching]

 



  _  

From: Simon Kitching [mailto:[EMAIL PROTECTED] 

> 
> I specified the URL to this pom in continuum 20040414. Continuum correctly
> added each of the child modules as a separate "project". However the SVN
> urls are not set right. For example, the "core" module thinks its svn path
> is:
> http://.../trunk/common-core
> when it should be using
> http://.../trunk/common/core

It's a problem in maven api.
maven use artifactId and not module name for path resolution. 

 [snip] 

I will therefore file a bug against maven.  
 
Hmm..on further thought, this approach just won't work. There's no reliable
way to deduce the scm url for a project from (scn url for parent) + (path
from project to parent). Example:
 "scm:svn:http://foo.example/dir1";  and "../dir1/pom.xml"
 isn't enough to realise that the project in question can be found at:
  scm:svn:http://foo.example/widget

However it seems to me that the safest option for Continuum would be to
calculate the scm url based on the scm url of the originally imported
module, and the module path to each project .
 
So the approach above would seem to be the only reliable one. The existing
maven approach of appending artifactId to the parent pom's scm url is really
just a heuristic (a guess that will work for some subset of valid
configurations only).
 
Alternately, an  block in each pom.xml is required.
 
This maven jira entry has some related info:
http://jira.codehaus.org/browse/MNG-1031
 
Regards,
 
Simon

RE: SVN paths when adding an m2 pom with module declarations

[Simon Kitching]

Hi Emmanuel,


  _  

From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 20, 2006 7:57 PM
To: continuum-users@maven.apache.org
Subject: Re: SVN paths when adding an m2 pom with module declarations




Simon Kitching a écrit :
> Hi,
> 
> I've got a pom with this:
> 
> scm:svn:http://.../trunk
> 
> 
> 
> common/core
> common/business
> transactions/transaction-server
> transactions/payment-server
> transactions/billing-server
> transactions/im_handset_sim
> management
> 
> 
> I specified the URL to this pom in continuum 20040414. Continuum correctly
> added each of the child modules as a separate "project". However the SVN
> urls are not set right. For example, the "core" module thinks its svn path
> is:
> http://.../trunk/common-core
> when it should be using
> http://.../trunk/common/core

It's a problem in maven api.
maven use artifactId and not module name for path resolution. 
 
Do you have set the parent relativePath in your modules if it isn't
../pom.xml (the default value) 
 
Yes, each of the modules has:
 

 system

com.gfggroup.mobile

1.0-SNAPSHOT

../../pom.xml

  

And yes, it makes sense that given the scm url of a parent pom, and the
relative path from project X to its parent, the scm url of project X can be
determined. But unfortunately it definitely isn't working that way for
continuum at the moment.

I tried your suggestion of "mvn help:effective-pom", and maven is definitely
not getting it right:

  
 
scm:svn:http://gfgdev4/svn/peregrine/trunk/transactions-txcore
http://gfgdev4/svn/peregrine/transactions-txcore
  

I will therefore file a bug against maven. 

However it seems to me that the safest option for Continuum would be to
calculate the scm url based on the scm url of the originally imported
module, and the module path to each project. After all, a pom can have
module declarations pointing to projects that have no parent. In this
situation, continuum has enough information to compute the scm urls (because
it's walking from the original pom down to the declared modules) even though
it's not possible to deduce the scm url by looking at each individual
project.


> 
> In other words, it's appending the child pom artifactId to the base scm
url,
> when it should be using the module path that led to that pom.
> 
> Is there any way to tell it what the correct URL is? I noticed that in
> continuum 1.0.2, I could click on the project name then use the "edit"
> button to modify the project details. I can't find how to do this in
> 20040414...any hints?

If the relativePath doesn't solve your pb, you should define the in your
modules. 

Yes, I guess I could put an  block in every pom in the tree, and will
do so now. 

Many thanks for your reply.

Regards,

Simon

NullPointerException: version was null

[Simon Kitching]

Hi,

I am trying to use the assembly:assembly goal. However when I run my pom, I
get the exception shown below.
Any ideas??

BTW, I'm pretty sure that when I looked at ibiblio a day or two ago, Spring
1.2.6 was the latest available on ibiblio. There is now an
org/springframework/spring/1.2.7 available. That dir doesn't have any
pom.xml file though; is that ok?

http://www.ibiblio.org/maven2/org/springframework/spring/1.2.7/

Regards,

Simon


[WARNING] Unable to get resource from repository central
(http://repo1.maven.org
/maven2)
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] version was null for org.springframework:spring
[INFO]

[INFO] Trace
java.lang.NullPointerException: version was null for
org.springframework:spring
at
org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtif
act.java:361)
at
org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:
222)
at
org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(
ResolutionNode.java:115)
at
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(D
efaultArtifactCollector.java:88)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:223)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:211)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:182)
at
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
ncies(DefaultPluginManager.java:1117)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:366)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:534)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SVN paths when adding an m2 pom with module declarations

[Simon Kitching]

Hi,

I've got a pom with this:
  
scm:svn:http://.../trunk
  

  
common/core
common/business
transactions/transaction-server
transactions/payment-server
transactions/billing-server
transactions/im_handset_sim
management
  

I specified the URL to this pom in continuum 20040414. Continuum correctly
added each of the child modules as a separate "project". However the SVN
urls are not set right. For example, the "core" module thinks its svn path
is:
  http://.../trunk/common-core
when it should be using
  http://.../trunk/common/core

In other words, it's appending the child pom artifactId to the base scm url,
when it should be using the module path that led to that pom.

Is there any way to tell it what the correct URL is? I noticed that in
continuum 1.0.2, I could click on the project name then use the "edit"
button to modify the project details. I can't find how to do this in
20040414...any hints?

Regards,

Simon

RE: struts config generation

[Simon Kitching]

Hi Dorileo,
 
I'm not sure if there is a better way, but you can always run an ant task or
ant buildfile from maven,
so you could use your existing solution for config file generation. See the
antrun plugin: 
  http://maven.apache.org/plugins/maven-antrun-plugin/introduction.html
 
http://maven.apache.org/plugins/maven-antrun-plugin/usage.html
 
Regards,
 
Simon

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 20, 2006 8:51 AM
To: users@maven.apache.org
Subject: struts config generation


Hi all!

I'm starting my first project using maven and I would like to know how to 
set maven up to generate the struts config file. I ever used ant/xdoclet 
to do so, but in maven 2 I couldn't find how to set it up. Could someone 
point me the direction?

thanks in advanced

Please cc me, I'm not subscribed in the list.

--
Dorileo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Customized directory structure to produce artifacts / classes ?

[Simon Kitching]

On Wed, 2006-04-19 at 12:43 +0200, Sharma, Jaikumar wrote:
> Dear Maven Users!
>  
> M2 build produces standard directory structure as a result of  build
> process, is it possible to override the same and customize --- compile,
> package, JAR, WAR, JavaDocs etc to the folder structure as per the
> organization specific directory standard ? or is it customizable in POMs ?

Yes, Maven2 can be configured via the POM to handle just about any
directory structure. Of course that's more complicated than using the
standard structures, but it's not too bad.

See the documentation on the maven site for:
  
  
  
  etc
as well as config attributes for specific plugins.

This page lists all the possible xml elements in a POM:
http://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html

One thing you will find very hard to work against, though, is maven's
desire to create one "artifact" (eg jar or war) per pom.xml file. Even
that's possible to work around in some cases, but only with significant
effort. There are very good reasons for maven's approach here of course.
So in practice if you want to apply Maven to existing projects you are
likely to need to make at least some changes in the project structure.

If you're just starting with maven2 then there's a great maven2 book
available via the mergere.com site:
  http://www.mergere.com/products.jsp

Regards,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Dependency Management, Prioritize Repositories - Internal, Central, etc.

[Simon Kitching]

On Wed, 2006-04-19 at 12:27 +0200, Jörg Schaible wrote:
> Roye, Suhneel BGI SF wrote on Wednesday, April 19, 2006 12:06 PM:
> 
> > Problem:
> > I have a custom JAR (built by our team) installed in my local
> > repository, and yet every time I do a build, Maven attempts
> > to download
> > it from Central (iBiblio) before realizing it's located in my local
> > repository. I would like to prevent Maven from attempting to download
> > this JAR from Central every time I do a build.
> > 
> > Existing Solution:
> > Has anyone successfully dealt with this problem? I've seen several
> > threads on this topic without any resolution. I do not want
> > to override
> > Central or disable downloading of JAR's from Central.
> > 
> > Potential Solution:
> > I would like to be able to specify the order in which Maven looks up
> > repositories. I would like for it to first look in my local
> > repository, then at a shared (corporate) repository, and finally go
> > out to the Central (iBiblio) repository. 
> 
> This will not really help, for SNAPSHOTs Maven has to look in every 
> repository.

True, for SNAPSHOT files.

If you're getting this problem with something other than SNAPSHOT files,
then did you use -DgeneratePom=true when installing the files? 

I've been working on doing exactly this kind of thing today, and it's
working fine. However if there is no pom file next to the jarfile in the
local repository, then maven tries to fetch the *pom* (and only the pom)
from the central repository, then gets the jar from the local one.
Putting a pom in the local repository fixes that.

Regards,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: use of proxies

[Simon Kitching]

On Fri, 2006-04-14 at 11:55 +0200, Emmanuel Venisse wrote:
> If you don't want to use repo1 repository but your own, you must define a 
> mirror in your 
> settings.xml like this:
> 
> 
>.
>.
>
>  
>local
>Local Mirror of http://repo1.maven.org/maven2/
>http://localhost/mvnrepos/lib
>central
>  
>
>.
>.
> 
> 
> If you use  in your pom instead of a mirror setting, maven will 
> add your repo in the 
> search list but won't replace repo1 by your own repo.

Is this the case even when the  tag in the pom has this?
  central

I was under the impression that this would override the "super-pom"
definition that pointed at the repo1.maven.org address...

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: use of proxies

[Simon Kitching]

Hi,

Note that there are two types of repositories (as was pointed out
earlier in this thread):
  -- holds "library" jars
and
  -- holds "plugin" jars

I believe that to completely disable downloading of *libraries* from the
standard "library" repository hosted by ibiblio (and aliased from
repo1.maven.org) you just define a  with id="central". This
overrides the standard definition. Defining a repository with any other
id just adds another possible location for maven to check.

In order to disable downloading of *plugins* from the standard
repository, you need to define a  with id=central. 

It looks to me like you've done the first of these, but not the second,
with the result that maven is still trying to download *plugins* from
repo1.maven.org.

Of course if you disable access to the internet for maven plugins,
you'll need to install every plugin that you need into your local plugin
repository, including things like maven-resources-plugin,
maven-compiler-plugin, etc. The maven "distribution" that is available
for download only contains the minimal core of maven; to do anything
practical with it extra plugins are needed (which get downloaded as
needed).

I'm not sure how marking a repository as a "mirror" fits in here.

Please note that I'm not an expert in this area; I'm still on the maven
learning curve. All the above is subject to correction by those who know
maven better...

Regards,

Simon


On Thu, 2006-04-13 at 18:13 -0400, EJ Ciramella wrote:
> So it seems there's no way to STOP maven from pulling these resources from 
> the web instead of my server? 
> 
> -Original Message-
> From: EJ Ciramella [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 13, 2006 3:30 PM
> To: Maven Users List
> Subject: RE: use of proxies
> 
> Take about 10 steps back and a deep breath - the problem is that the security 
> forces that be don't like the fact that anything can be placed up there 
> (http://repo1.maven.org/maven2) and then pulled down.
> 
> In addition to this, why oh why is maven downloading something remotely that 
> exist within our four walls?
> 
> How do I stop this?
> 
> E:\work\foxboro\model>mvn process-resources
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building LtyModel
> [INFO]task-segment: [process-resources]
> [INFO] 
> 
> [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for 
> updates from local-central
> [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for 
> updates from central
> Downloading: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.1/maven-resources-plugin-2.1.pom
> 888b downloaded
> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for 
> updates from local-central
> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for 
> updates from central
> Downloading: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.1/maven-compiler-plugin-2.0.1.pom
> 1K downloaded
> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for 
> updates from local-central
> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for 
> updates from central
> Downloading: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.1.3/maven-surefire-plugin-2.1.3.pom
> 1K downloaded
> [INFO] artifact org.apache.maven.plugins:maven-javadoc-plugin: checking for 
> updates from local-central
> [INFO] artifact org.apache.maven.plugins:maven-javadoc-plugin: checking for 
> updates from central
> Downloading: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/2.0-beta-3/maven-javadoc-plugin-2.0-beta-3.pom
> 
> -Original Message-
> From: Gunther Popp [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 13, 2006 1:51 PM
> To: Maven Users List
> Subject: Re: use of proxies
> 
> >The first question is: why?
> 
> Sorry, for jumping in here, but a common reason is to guarantee 
> reproducible builds over a fairly long period of time. For example, the 
> systems I´m engaged with have a typical lifetime of 15-20 years. When 
> the software is considered stable after initial development, a team of 
> maintenance developers will implement enhancements and fix bugs. These 
> guys are typically responsible for several systems and have no time to 
> hassle around with build tools. So the build process simply should work.
> 
> You cannot guarantee this, if your build relies on any form of external 
> resource that is not under your direct control. Even if I use explicit 
> version numbering for plugins and dependencies, the corresponding 
> artifacts simply may disappear on iblio in five years from now. Or, 
> another scenario, maybe the repository layout changes in Maven 3 or 4 
> and "legacy" Maven 2 re

Re: Override a phase?

[Simon Kitching]

On Wed, 2006-04-12 at 06:42 -0700, Kevin Carroll wrote:
> Is there any way to override a phase?  I am building a jar file that needs to 
> pull in
> dependencies so I have a custom ant task (classdepandjar) that does it.  The 
> maven
> lifecycle still executes the default package phase and builds the jar for the 
> project.  I
> don't need that jar and I would like to just eliminate it from being built.  

You can't override the phase bindings set up by your 
declaration. You can only add to it via  tags.

However some plugins can effectively be configured as "disabled"; see
the plugin's options (eg surefire has true).

As noted by another poster, using pom doesn't set up
any phase bindings so you can start from scratch and define everything
you want explicitly.

Regards,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Specifying the location of web.xml in the POM

[Simon Kitching]

On Tue, 2006-04-11 at 22:42 +0100, Gareth Western wrote:
> Hi,
> 
> I'm playing around with an old project in Maven, trying to see how to
> upgrade our current build scripts. Unfortunately we do not use the
> recommended directory structures, therefore I've specified an alternate
> sourceDirectory (src) and outputDirectory
> (classes) in the project's POM. This
> particular artifact is a WAR, therefore it needs to include the web.xml from
> a directory named "webapp" which is located in the same directory as the
> "src" directory. How do I specify this in the POM? Is it a ?
> 

Perhaps you're looking for the  tag (which should
point to the root dir of the webapp, ie the dir with WEB-INF as a
subdir)?

http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [M2] How to ensure reproducible releases?

[Simon Kitching]

On Mon, 2006-04-10 at 12:17 +0200, Jörg Schaible wrote:
> Hello folks,
> 
> what is the best way to ensure reproducible releases in M2? By default Maven 
> will update its plugins and dependencies from time to time - which is fine as 
> long as I work on the trunk. But when I release an artifact, I must freeze 
> the current set of plugins/versions for this release - how can I achieve that?
> 
> Otherwise M2 might just break the reproducibility of such a release - as it 
> happened for me today with the new surefire plugin: forkMode "perTest" was 
> renamed in the latest release to "pertest". Any release done with the old 
> version is not longer reproducible! The build is broken, because the new 
> version of the plugin fails with an unknown fork mode.

I've seen in the documentation that you can specify versions like this:
 [2.2]

I believe this explicitly locks the dependency at *exactly* that
version. Presumably this works for plugin versions too.

And it should make things work faster too, as Maven has no need to check
remote repositories for newer versions if an exact version is specified
and is already available (well, I'm guessing it works like that).

Cheers,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to pack two jars in one project?

[Simon Kitching]

On Wed, 2006-03-29 at 13:32 +0200, Dennis Kempin wrote:
> Hello,
> 
> I just discovered maven and I am really impressed by this project!
> To migrate my project to maven I am searching for a way to create two jar  
> files in one project.
> 
> I would like to have a "./src/main/api" folder besides "./src/main/java"  
> and pack them into two different jars, to provide a single jar that only  
> contains the API that is needed to use my library.
> 
> For now I use two seperated projects "core" and "core-api" while "core"  
> depends on "core-api". This also works great, but I think it would be more  
> elegant to have the API in the same project that will create a  
> "core-api-version.jar" besides the "core-version.jar".
> 
> Do you think that it is possible? Or do you think I should stay at the  
> seperated projects due to some reasons (Maybe because implementation  
> versions can change while API versions stay at a specific version).

I think you'll find it very difficult to have one maven project for
this. Maven really is designed for one project --> one output artefact.

Anyway, you must have had a reason for separating api from core in the
first place, yes? Presumably you either expect multiple implementations
of the api or multiple releases of the implementation without changing
the api. In either case, having separate projects seems to me to be much
*better* than having one project.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]