Re: Why would maven look for a newer version of a plugin?

[Sanjeeb Sahoo]

No, that snippet is part of pluginManagement. The actual usage is inside 
, but there is no version specified at the point of use. Why 
should version be specified there if it is already present in 
pluginManagement? BTW, in case I didn't make it clear, I am looking at 
effective pom. Our project POM does not even have an entry for javadoc 
plugin under ; it's inherited from SuperPOM.


Sahoo
On Friday 12 November 2010 08:53 PM, Frederic Camblor wrote:

Hi,

Is your snippet extracted from the  or the  pom section ?

Check that your version is provided on both of these sections (even if you
provided it in /project/build/pluginManagement)

Frédéric

On Fri, Nov 12, 2010 at 3:29 PM, Sanjeeb Sahoo  wrote:

   

I would like someone to help us understand a behavior that we recently
observed in our build system. In our project POM, we don't explicitly
mention the versions for these plugins, as we expect the versions to be
inherited from SuperPOM. When I look at the effective POM for the project,
it shows the following configuration for javadoc plugin:


maven-javadoc-plugin
2.5


yet, when I try to build (I am using maven 2.2.1), I get this error:

[INFO] [ERROR] BUILD FAILURE
[INFO] [INFO]

[INFO] [INFO] A required plugin was not found: Plugin could not be found -
check that the goal name is correct: Unable to download the artifact from
any repository
[INFO]
[INFO] Try downloading the file manually from the project website.
[INFO]
[INFO] Then, install it using the command:
[INFO] mvn install:install-file -DgroupId=org.apache.maven.plugins
-DartifactId=maven-javadoc-plugin -Dversion=2.8-SNAPSHOT
-Dpackaging=maven-plugin -Dfile=/path/to/file
[INFO]
[INFO] Alternatively, if you host your own repository you can deploy the
file there:
[INFO] mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins
-DartifactId=maven-javadoc-plugin -Dversion=2.8-SNAPSHOT
-Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
-DrepositoryId=[id]
[INFO]
[INFO]
[INFO]
org.apache.maven.plugins:maven-javadoc-plugin:maven-plugin:2.8-SNAPSHOT
[INFO]
[INFO] from the specified remote repositories:
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   glassfish-maven-repository (
http://maven.glassfish.org/content/groups/glassfish-group/)

We started seeing this after the maven-metadata in our nexus repo, which is
configured to proxy only released artifacts, got updated with SNAPSHOT
artifact details. The nexus repo issue has been fixed after upgrading to
1.8.0, but what is not understood is why maven even attempted to use
2.8-SNAPSHOT when effective pom shows the plugin version as 2.5.

Thanks,
Sahoo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


 
   



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Why would maven look for a newer version of a plugin?

[Sanjeeb Sahoo]

I would like someone to help us understand a behavior that we recently 
observed in our build system. In our project POM, we don't explicitly 
mention the versions for these plugins, as we expect the versions to be 
inherited from SuperPOM. When I look at the effective POM for the 
project, it shows the following configuration for javadoc plugin:



maven-javadoc-plugin
2.5


yet, when I try to build (I am using maven 2.2.1), I get this error:

[INFO] [ERROR] BUILD FAILURE
[INFO] [INFO] 

[INFO] [INFO] A required plugin was not found: Plugin could not be found 
- check that the goal name is correct: Unable to download the artifact 
from any repository

[INFO]
[INFO] Try downloading the file manually from the project website.
[INFO]
[INFO] Then, install it using the command:
[INFO] mvn install:install-file -DgroupId=org.apache.maven.plugins 
-DartifactId=maven-javadoc-plugin -Dversion=2.8-SNAPSHOT 
-Dpackaging=maven-plugin -Dfile=/path/to/file

[INFO]
[INFO] Alternatively, if you host your own repository you can deploy the 
file there:
[INFO] mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins 
-DartifactId=maven-javadoc-plugin -Dversion=2.8-SNAPSHOT 
-Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] 
-DrepositoryId=[id]

[INFO]
[INFO]
[INFO]   
org.apache.maven.plugins:maven-javadoc-plugin:maven-plugin:2.8-SNAPSHOT

[INFO]
[INFO] from the specified remote repositories:
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   glassfish-maven-repository 
(http://maven.glassfish.org/content/groups/glassfish-group/)


We started seeing this after the maven-metadata in our nexus repo, which 
is configured to proxy only released artifacts, got updated with 
SNAPSHOT artifact details. The nexus repo issue has been fixed after 
upgrading to 1.8.0, but what is not understood is why maven even 
attempted to use 2.8-SNAPSHOT when effective pom shows the plugin 
version as 2.5.


Thanks,
Sahoo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why are repositories usually separated into releases and snapshots?

[Sahoo]

Sometime back I had the exact question in my mind and QoS (what you 
mentioned as administration) and security were the only ones I could 
think of.


Thanks,
Sahoo

David Weintraub wrote:

No one has answered the basic question: Why two repositories?

I know the differences between a release and snapshot. but that doesn't
explain why the releases and snapshots are in two separate repositories. Why
not keep both snapshots and releases in the same repository. We know
something is a snapshot simply because it has the word "SNAPSHOT" appended
to it.

Because of the dual repository structure, I have to configure everything
with two separate repository names, two separate repository URLs, and two
sets of accounts and passwords. So, why not simply have a single repository
which can store both snapshots and releases?

These are the only reasons I can think of:

* Administration: Backing up a release repository is extremely important.
Backing up snapshots -- not so much. But, is this actually true?

* Who can see what. I might want my snapshot repository available to my
developers, but not to the world. However, this would be more of something
my repository management software should be able to do.

* Releases should only be added to the release repository by a release
manager, and not by any developer. However, snapshots would be added by
developers. Again, this seems better handled via my repository management
software.

So, what is the reason to have two separate and distinct repositories for
snapshots and for releases?

On Thu, Oct 22, 2009 at 4:43 AM, Costin Caraivan wrote:

  

Hello,

I saw that most repositories are separated into releases and snapshots. And
that most repository managers recommend using releases and snapshots.

Now, I know what each of them is:
1. release -> stable version, will be uploaded only once, when you want to
change something you make a new release.
2. snapshots -> development version, usually overwritten (you can keep
multiple snapshots, but it's not usually done)

What are the benefits of having 2 separate repos? Cons & pros. Pros & cons
:)
--
View this message in context:
http://www.nabble.com/Why-are-repositories-usually-separated-into-releases-and-snapshots--tp26006147p26006147.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org






  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Failed deployment of Maven project to Glassfish

[Sahoo]

Glad your issue is resolved. I doubt verifier was wrong in pointing out 
that a required class was missing.


Thanks,
Sahoo

dtiodtio wrote:

Apologies for the misplaced post.

The issue went away by installing the jersey bundle instead of the
particular artifact javax.ws.rs

Also, the verifier indeed was a bit too picky by suggesting the build would
fail when it actually was working.

Thanks anyway,
Dimitris




On Tue, Oct 6, 2009 at 11:15 AM, Entner Harald  wrote:

  

Does the jar reside in the war file?

-Ursprüngliche Nachricht-
Von: diafa...@gmail.com [mailto:diafa...@gmail.com] Im Auftrag von
dtiodtio
Gesendet: Samstag, 3. Oktober 2009 21:49
An: users@maven.apache.org
Betreff: Failed deployment of Maven project to Glassfish

Hello,

I recently converted from ant to maven and I'm now trying to deploy to
GlassFish the Maven .war of a multimodule project. The .war file is built
successfully with its dependencies (using the NetBeans IDE) and deployed
using the GlassFish Admin Console (still don't have the hang of deploying
through NetBeans using plugins). However, deployment fails with the given
server.log message (as produced by checking the Verifier flag in the Admin
Console):

Failed to find following classes:
[
   javax.ws.rs.core.ApplicationConfig
]

referenced in the following call stack :

   at com.sun.jersey.api.core.ResourceConfig
   at com.sun.jersey.api.core.DefaultResourceConfig
   at com.sun.jersey.api.core.ApplicationConfigAdapter
   at com.sun.jersey.spi.container.servlet.ServletContainer

However, I have the following entry

   
 javax.ws.rs
 jsr311-api
 1.1
 compile
   

in the .war pom.xml

Is this a bug or am I doing something wrong?

Thanks in advance

Dimitris




  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Failed deployment of Maven project to Glassfish

[Sahoo]

This is not a maven issue. You need to ask this question in GlassFish 
forum (us...@glassfish.dev.java.net). Have you tried deploying 
by-passing verifier by turning off verifier flag? Does the app work? If 
yes, I guess it is a false failure reported by verifier. In any case, 
don't reply here. Ask your question in GlassFish forum.


Sahoo

dtiodtio wrote:

Hello,

I recently converted from ant to maven and I'm now trying to deploy to
GlassFish the Maven .war of a multimodule project. The .war file is built
successfully with its dependencies (using the NetBeans IDE) and deployed
using the GlassFish Admin Console (still don't have the hang of deploying
through NetBeans using plugins). However, deployment fails with the given
server.log message (as produced by checking the Verifier flag in the Admin
Console):

Failed to find following classes:
[
javax.ws.rs.core.ApplicationConfig
]

referenced in the following call stack :

at com.sun.jersey.api.core.ResourceConfig
at com.sun.jersey.api.core.DefaultResourceConfig
at com.sun.jersey.api.core.ApplicationConfigAdapter
at com.sun.jersey.spi.container.servlet.ServletContainer

However, I have the following entry


  javax.ws.rs
  jsr311-api
  1.1
  compile


in the .war pom.xml

Is this a bug or am I doing something wrong?

Thanks in advance

Dimitris

  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven reactor plugin and build order

[Sahoo]

While trying to use reactor:resume to resume a build, I see the order of 
build changing. See the output below. The order as reported initially is 
not same as the order reactor plugin is following. Why?


glassf...@~/WS/gf/v3.trunk.new$  mvn reactor:resume -DprintOnly=true 
-Dfrom=packager/glassfish-nucleus/

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   GlassFish Parent Project
...
[INFO]   Glassfish Nucleus Package
...
[INFO]   App Client Modules
...
[INFO]   Sun Java EE Engine

[INFO] Searching repository for plugin with prefix: 'reactor'.
...
[INFO] [reactor:resume]
[INFO] Executing: /bin/sh -c ...
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   App Client Modules
...
[INFO]   Glassfish Nucleus Package
...
[INFO]   Sun Java EE Engine


Thanks,
Sahoo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How include DLLs in manifest class path?

[Sahoo]

I don't think dlls are looked up in classpath. JVM locates them using 
java.library.path value. IIRC, this property includes PATH value in 
Windows and LD_LIBRARY_PATH on Unix. You can add your own directory path 
to either the property or to appropriate environment property.


Thanks,
Sahoo

marc2020 wrote:

I've just mavenised a project which contained several 3rd party DLLs

I've included the DLLs in the POM as dependancies, with the type = dll

When the project is built, the lib folder correctly contains all the DLLs -
however, at the point my project attempts to call functions in a DLL,
classes in that DLL cannot be found.

I believe the problem is, when the jar is built, the manifest doesn't
reference any of the DLLs in the class-path section. It only contains JARs,
despite them being dependancies in the POM


How can I alter the POM, such Maven references the DLLs in the manifest's
class-path?

Thanks for any help !!


  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why is version 2.0 NOT same as 2.0.0?

[Sahoo]

Well, I wrote a simple program to compare the two versions and it 
reports 2.0 to be same as 2.0.0.


// Main.java
import org.apache.maven.artifact.versioning.DefaultArtifactVersion;

class Main {
 public static void main(String... args) {
   if (args.length == 1) {
 DefaultArtifactVersion mv = new DefaultArtifactVersion(args[0]);
 System.out.println(mv.getMajorVersion() + ", " + 
mv.getMinorVersion() + ", " +
mv.getIncrementalVersion() + ", " + 
mv.getQualifier());

   } else {
 DefaultArtifactVersion mv1 = new DefaultArtifactVersion(args[0]);
 DefaultArtifactVersion mv2 = new DefaultArtifactVersion(args[1]);
 System.out.println(mv1.compareTo(mv2));  
   }

 }
}

Thanks,
Sahoo
Jim Sellers wrote:

I assume that maven treats them as Strings internally, not doubles.

Just like version 3.0-RC1 and 1.0.3-beta3 are valid versions.

HTH
Jim


On Sat, Jun 13, 2009 at 11:17 AM, Sahoo  wrote:

  

It's quite annoying to see that some code path in maven (I am on version
2.0.9) does not think 2.0 is same as 2.0.0. I just tried to configure
maven-bundle-plugin and specified the version as 2.0 and maven failed to
locate the version. See error message below:

/Reason: POM 'org.apache.felix:maven-bundle-plugin' not found in
repository: Unable to download the artifact from any repository

 org.apache.felix:maven-bundle-plugin:pom:2.0
/
As soon as I specified the version as 2.0.0, it found it. Strange, I must
say.

Thanks,
Sahoo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Why is version 2.0 NOT same as 2.0.0?

[Sahoo]

It's quite annoying to see that some code path in maven (I am on version 
2.0.9) does not think 2.0 is same as 2.0.0. I just tried to configure 
maven-bundle-plugin and specified the version as 2.0 and maven failed to 
locate the version. See error message below:


/Reason: POM 'org.apache.felix:maven-bundle-plugin' not found in 
repository: Unable to download the artifact from any repository


 org.apache.felix:maven-bundle-plugin:pom:2.0
/
As soon as I specified the version as 2.0.0, it found it. Strange, I 
must say.


Thanks,
Sahoo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How can one handle release candidates in Maven?

[Sahoo]

Brian,

Thank you for taking time to answer.

Sahoo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How can one handle release candidates in Maven?

[Sahoo]

Brian,

Thanks for the excellent write up. In approach #2, when a build is done 
by just replacing RC versions by actual versions, since new binaries are 
going to be produced, don't they have to be tested again? I understand 
since no source code is changed(only version is changing in pom.xmls), 
the chances of side effects are very low, but an organisation with 
stricter quality control processes in place won't allow bits to be 
released without them being tested. Once you involve testing, we are 
back to square one, where we are not sure if the bits are final. Or, am 
I missing anything?


Thanks,
Sahoo

Brian Fox wrote:

First, I'll acknowledge that it's not easy/possible to "promote" an artifact
from one version to another - say 1.0-RC-10 to 1.0. Lets just accept that
for now as it's a known issue that will be resolved down the road. Lets
instead discuss a few ways to work within those bounds, since discussing
what "could be" doesn't help the issue now (which i believe this thread
derived from the discussion on commons-dev regarding a pending release).
There are two approaches to this process, both are valid and I think you
could pick one based on your requirements:

The first is to append a build number to your version that is always
incremented. So instead of 1.0 you have 1.0-1 or 1.0-b1. You increment this
forever until you have a release that is good and that's the one that stays,
it could be 1.0-b10 or 1.0-500. I've used this approach before and it's
similar to what many commercial orgs do (if you look under the hood at MS
versions for example, Vista SP1 is 6001.16659.070916-1443). In other words,
the marketing for a release might be "1.0" but the actual version of the
files might be 1.0-. This may be ok for things where the end result is a
war or ear but probably not as desirable for projects like commons that
release jars that are intended to be consumed.


The approach we use in the Maven project is slightly different. We used to
stage versions like 2.0.8 over and over until we got it right. The problems
with this approach where: 1) you need to rollback the tag and versions every
time and 2) someone may have an artifact called 2.0.8 that was actually not
the final 2.0.8. This was a bigger problem when we wanted to start getting
maven-users involved to test the release candidates.

We instead use the RC versions (eg 2.0.9-RC10) until we get to a release
that we decide is ready to do. The versions are all staged on Nexus and the
binaries are ditched each time we rebuild, but the tags stay in place. Since
each release is uniquely versioned, we no longer have to revert the versions
and we don't have to worry about someone having an RC and thinking it's a
final release. Since it's not possible currently to promote an actual RC to
the final release (eg 2.0.9-RC10 to 2.0.9), we simply rebuild and restage
one final time using the new release number (eg 2.0.9). The original RCs
were never called for formal votes as we know it's unlikely to pass, think
of them as tagged snapshots. Only the final release is voted upon and in
this fashion, by the time we reach the final release it's highly unlikely we
will find any showstoppers, since the release process was followed for each
RC (a practice run 10+ times if you will).

Yes there are issues where someone _could_ make a change in between the last
RC and the final release, but when we are in this cycle it is expected that
only the RM is making changes to that branch (once the RC process starts,
it's moved to a separate branch) and it's watched very closely. In reality
it's not an issue.

Hope that helps.
Brian

On Thu, May 14, 2009 at 5:35 AM, Anders Hammar  wrote:

  

Hi,

I don't mean to hijack this thread, but my experience is that test
people love traceability. Thus, I think they would expect a created
tag/label to stay as they file bug reports on it. (I guess this is out
of a larger non-agile organization's point of view.)

Just my 2 cents,
/Anders

On Wed, May 13, 2009 at 16:41, sebb  wrote:


On 13/05/2009, Jason van Zyl  wrote:
  

 On 13-May-09, at 10:11 AM, sebb wrote:




On 13/05/2009, nicolas de loof  wrote:

  

With this approach, all RC tags (and the final one) point to a


source


code


that generate the finalName artifact.
more complete sample



Yes, but AFAICS the tag 1.0 points to different code at different
times, so does not uniquely identify the code.


  

 Tags should not contain different code at different points in time.


That's


just a bad practice. It happens by accident occasionally but to change


code


on tags consciously is just a bad practice.


I entirely agree.

However AFAICT that is exactly what many Maven release procedures
involve, because the tag is deleted and recreated.

To go 

Re: default plugin version

[Sahoo]

Thank you. I shall send a note to maven-antlr-plugin group.

Thanks,
Sahoo

Stephen Connolly wrote:

You do not have to specify the version if you are happy with how Maven
determines the versions.  Also if you do not specify the version your build
is not reproducible.

Can you please file a JIRA against the antlr-maven-plugin to get the usage
page to show the version in accordance with best practice.

Thanks,

-Stephen

P.S. you should not be happy with how maven determines which version of a
plugin to use... primarily because it is out of your control and relies on
the correct metadata.xml files in the repositories available to you... and
if you build a project which has defined additional repositories and those
repositories contain different metadata for the same plugin and the project
uses that plugin, you can even corrupt the metadata such that your build
breaks.

Another thing is that for plugins, you really have to follow the maven
version number rules or else lock down the version number.

2009/4/30 Sahoo 

  

Hi,

I always thought I had to specify the version while trying to use a custom
plugin, but that seems not to be the case. e.g., see [1] which does not
specify the plugin version. In such a case, which version is picked up.

Thanks,
Sahoo

[1] http://mojo.codehaus.org/antlr-maven-plugin/usage.html

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

default plugin version

[Sahoo]

Hi,

I always thought I had to specify the version while trying to use a 
custom plugin, but that seems not to be the case. e.g., see [1] which 
does not specify the plugin version. In such a case, which version is 
picked up.


Thanks,
Sahoo

[1] http://mojo.codehaus.org/antlr-maven-plugin/usage.html

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: ejb and bundle (OSGi)

[Sahoo]

You can explicitly call the goals of maven-bundle-plugin to do necessary 
OSGi bundling if you don't want to change the packaging type. See 
"Adding OSGi metadata to existing projects without changing the 
packaging type" section at 
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html


Thanks,
Sahoo
Jean-Claude wrote:

Hi,

We have a maven module containing EJBs. Therefore the packaging must be ejb.
This allows us to create an ear file containing these EJBs as ejbModule (see 
http://maven.apache.org/plugins/maven-ear-plugin/ maven-ear-plugin ).


But these EJBs are also used by an Eclipse Client and we want to package
them as an OSGi bundle. Therefore the packaging must be bundle (see 
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

maven-bundle-plugin ).

How can I achieve to package the EJBs so that they can be used as EJBs and
OSGi bundles?

Thank you for your help
J.-Claudeo
  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How can I force maven download dependency?

[Sahoo]

If it silently ignores, then it is too bad. Let's hope someone can 
confirm the behavior.


Stephen Connolly wrote:

AFAIK, it silently ignores the second deploy in newer versions of the
maven-deploy-plugin but I could be wrong

2009/3/10 Sahoo 

  

Although this is a core assumption in maven, many people don't know this.
The question that I have is why does maven not try to protect itself from
human error? Should mvn-deploy not refuse to overwrite an artifact by
default?

Sahoo


Stephen Connolly wrote:



The core assumption of a maven repository is that once a non-SNAPSHOT
version is available, that artifact will *NEVER* change.

Thus once maven downloads log4j:log4j:1.2.13 it will *NEVER* look for it
again.

This is why you should always keep your pom on a -SNAPSHOT version, as the
only thing that Maven will look for newer versions of are -SNAPSHOT
versions.

Now it sounds like you've been bold and have been deploying different
versions of an artifact with the same version number... the solution for
you
is to delete the artifact you don't want from your repository and then
maven
will be forced to download it again (as it no longer has a copy)

Yes this is a pain to do this by hand... consider it a penance for
deploying
different versions of the same artifact with the same version number ;-)

-Stephen

2009/3/10 youhaodeyi 



  

Maven will not download dependency from remote repository if the
dependency
already exists. How can I force Maven download the dependency even if the
dependency exists?
--
View this message in context:

http://www.nabble.com/How-can-I-force-maven-download-dependency--tp22428816p22428816.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org







  

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How can I force maven download dependency?

[Sahoo]

Although this is a core assumption in maven, many people don't know 
this. The question that I have is why does maven not try to protect 
itself from human error? Should mvn-deploy not refuse to overwrite an 
artifact by default?


Sahoo

Stephen Connolly wrote:

The core assumption of a maven repository is that once a non-SNAPSHOT
version is available, that artifact will *NEVER* change.

Thus once maven downloads log4j:log4j:1.2.13 it will *NEVER* look for it
again.

This is why you should always keep your pom on a -SNAPSHOT version, as the
only thing that Maven will look for newer versions of are -SNAPSHOT
versions.

Now it sounds like you've been bold and have been deploying different
versions of an artifact with the same version number... the solution for you
is to delete the artifact you don't want from your repository and then maven
will be forced to download it again (as it no longer has a copy)

Yes this is a pain to do this by hand... consider it a penance for deploying
different versions of the same artifact with the same version number ;-)

-Stephen

2009/3/10 youhaodeyi 

  

Maven will not download dependency from remote repository if the dependency
already exists. How can I force Maven download the dependency even if the
dependency exists?
--
View this message in context:
http://www.nabble.com/How-can-I-force-maven-download-dependency--tp22428816p22428816.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[Fwd: Where can I find more information on maven-metadata-local.xml?]

[Sahoo]

Someone in this alias must be knowing the answer, right?
--- Begin Message ---

Hi,

Where can I find more information on maven-metadata-local.xml? I want to 
understand meaning of entries specified in the file. e.g., what's the 
meaning of true under ? What causes 
this entry to be added? I see some snapshot artifacts in my local repo 
have this entry and some don't. How does this affect maven execution. I 
am using mvn 2.0.9.


Thanks,
Sahoo



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


--- End Message ---
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Where can I find more information on maven-metadata-local.xml?

[Sahoo]

Hi,

Where can I find more information on maven-metadata-local.xml? I want to 
understand meaning of entries specified in the file. e.g., what's the 
meaning of true under ? What causes 
this entry to be added? I see some snapshot artifacts in my local repo 
have this entry and some don't. How does this affect maven execution. I 
am using mvn 2.0.9.


Thanks,
Sahoo



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Does maven not use VERSION while detecting circular dependencies?

[Sahoo]

Geoffrey Wiseman wrote:

On Sun, Feb 8, 2009 at 10:07 AM, Sahoo  wrote:

  

It appears to me that maven does not use VERSIONs while calculating
circular dependencies. Is this true? Here is error I got:

[INFO] The projects in the reactor contain a cyclic reference: Edge between
'Vertex{label='xxx:hk2-maven-plugin'}' and 'Vertex{label='xxx:hk2-maven'}'
introduces to cycle in the graph
xxx:hk2-maven --> xxx:hk2-core --> xxx:hk2-maven-plugin --> xxx:hk2-maven

If versions of various artifacts were included, the above graph would have
looked like this:
xxx:hk2-maven:2.0-SNAPSHOT --> xxx:hk2-core:2.0-SNAPSHOT -->
xxx:hk2-maven-plugin:1.0 --> xxx:hk2-maven:1.0.

As you can see, the latter graph does not have any cycle. /Why does maven
not use VERSION while detecting cycles?/




Typically Maven resolves versions for you -- for instance, if I depend on
Hibernate 3.0 and Commons Lang 1.3 and Hibernate depends on Commons Lang
1.4, I'll only end up with Commons Lang 1.4 at the end -- it uses the
Version to determine which is likely to be the required version, but it
won't actually include both.

There's probably a better description somewhere than I've just given.  :)

With that in mind, I wouldn't expect it to consider the version in cyclical
dependency checks.

  - Geoffrey

This is too limiting IMO.

Sahoo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Does maven not use VERSION while detecting circular dependencies?

[Sahoo]

Hi,

It appears to me that maven does not use VERSIONs while calculating 
circular dependencies. Is this true? Here is error I got:


[INFO] The projects in the reactor contain a cyclic reference: Edge 
between 'Vertex{label='xxx:hk2-maven-plugin'}' and 
'Vertex{label='xxx:hk2-maven'}' introduces to cycle in the graph

xxx:hk2-maven --> xxx:hk2-core --> xxx:hk2-maven-plugin --> xxx:hk2-maven

If versions of various artifacts were included, the above graph would 
have looked like this:
xxx:hk2-maven:2.0-SNAPSHOT --> xxx:hk2-core:2.0-SNAPSHOT --> 
xxx:hk2-maven-plugin:1.0 --> xxx:hk2-maven:1.0.


As you can see, the latter graph does not have any cycle. /Why does 
maven not use VERSION while detecting cycles?/


Thanks,
Sahoo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Which is the right findbugs plugin?

[Sahoo]

I see two findbugs plugins:
maven-findbugs-plugin [1] and findbugs-maven-plugin [2]. Which one is 
recommended? Looking at the activity, I see [1] is not updated for a 
long time, so does it mean [2] is the one to use?


Thanks,
Sahoo

[1] http://maven-plugins.sourceforge.net/maven-findbugs-plugin/index.html
[2] http://mojo.codehaus.org/findbugs-maven-plugin/usage.html

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: unable to set repo loc using maven release plugin 2.0-beta-8

[Sahoo]

Even I faced similar issue while using release-plugin. Since I do 
parallel builds, I can't rely on ~/.m2/repository for all my builds, so 
I must different local repo. Any help is appreciated.


Thanks,
Sahoo

Jane Young wrote:

Hi Release Plugin  Gurus,

I want to specify a local maven repo.
Using maven release plugin 2.0-beta-8, I tried the combinations of  
"-Darguments=-Dmaven.repo.local=...", "-Darguments=-Dmaven.home...", 
-DlocalRepoDirectory=..." and/or "-DmavenHome=...", it always return 
/.m2/repository not found.


Is this a known issue?  Is there a workaround?
This was working in 2.0-beta-7.  However, in the 2.0-beta-7 release, 
the parameters releaseVersion and developmentVersion are not working.  
See: http://jira.codehaus.org/browse/MRELEASE-389


Thanks,
Jane

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to compile a plugin and use it in the same project?

[Sahoo]

There are some ways to do it, e.g., by configuring extensions, but my 
sincere suggestion is to separate them to different reactors. Having 
them in same reactor can lead to updation of the plugin jar in local 
maven repo while it is opened for reading and that will cause JDK to bomb.


RustamAbd wrote:

I have the following project structure:

parent
+ my-plugin
+ my-jar

How can I use my-plugin during building of my-jar, without having to install
my-plugin first?

Simply specifying it as a dependency doesn't work...

Please someone help...

Rusty
  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[Fwd: release:perform and scmCommentPrefix]

[Sahoo]

Any comments?
--- Begin Message ---
Can anyone clarify when scmCommentPrefix is used during release:perform 
[1] goal? I thought all the necessary changes in SCM happen during 
release:prepare and release:perform just checks out the project and runs 
necessary goals.


Thanks,
Sahoo

[1] http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


--- End Message ---
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

release:perform and scmCommentPrefix

[Sahoo]

Can anyone clarify when scmCommentPrefix is used during release:perform 
[1] goal? I thought all the necessary changes in SCM happen during 
release:prepare and release:perform just checks out the project and runs 
necessary goals.


Thanks,
Sahoo

[1] http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-release-plugin removes comments

[Sahoo]

Issue #255 has been fixed in maven-release-plugin version 2.0-beta-8 and 
that indeed fixed my issue.


Thanks,
Sahoo

Wim Deblauwe wrote:

A quick search in jira makes you think it should have been fixed:
http://jira.codehaus.org/browse/MRELEASE-255, although this related bug (
http://jira.codehaus.org/browse/MRELEASE-266) is still open.

Not sure if all comments are left alone or just specific things?

regards,

Wim

2008/10/30 Sahoo <[EMAIL PROTECTED]>

  

My pom.xml looks like this:



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
...


I am  doing a dryRun of mvn release:branch. I see that the above comment is
removed by maven. How can I avoid it?

Thanks,
Sahoo

-
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]

maven-release-plugin removes comments

[Sahoo]

My pom.xml looks like this:



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
...


I am  doing a dryRun of mvn release:branch. I see that the above comment 
is removed by maven. How can I avoid it?


Thanks,
Sahoo

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

Re: maven 2.0.7 reorders dependencies during build causing compilation failures

[Sahoo]

Yes, I have and I don't see any problem. It is impossible to enforce 
every artifact in the transitive closure depends on same version of an 
artifact. Different artifacts evolve at different pace, while some may 
have a dependency on lower versions, some may require higher versions. 
It's not just about different versions of same artifact, sometimes 
different artifacts may have same classes in them and you may like to 
use classes from a particular artifact because that contains the correct 
version of classes you are looking for.


More over, we (in GlassFish project) use OSGi, so when someone takes our 
artifact, they can always inspect all its dependencies and ensure they 
are met in their environment. If they don't ensure, they will get a nice 
message that will tell them that desired version of a package is not 
available.


I hope you are not defending the unpredictable behavior of maven version 
< 2.0.9.


Michael McCallum wrote:
did you ever think that something is seriously wrong if the classpath ordering 
causes your build to fail? 

That could mean that sometime somewher someone will deploy your application 
and use a different order for the jars and it just won't run and the poor 
developer/ops person will have no idea...



  


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

Re: maven 2.0.7 reorders dependencies during build causing compilation failures

[Sahoo]

Barrie Treloar wrote:

On Sat, Oct 18, 2008 at 3:38 PM, Sahoo <[EMAIL PROTECTED]> wrote:
  

I just don't believe what I am seeing. Despite adding a particular
dependency directly in my pom.xml, maven reorders dependencies and hence we
get compilation failure. e.g., take a look at the pom.xml available at [1].
It declares a direct dependency on
   
  org.glassfish
  javax.servlet
  ${project.version}
   



Yes.

Use 2.0.9

Dependencies were just HashMaps previously hence the order is random.
The dependency order is preserved in 2.0.9 but I cant remember what
ordering it used.
  
Sorry to ask again. Was the dependency order random in all versions 
previous to 2.0.9? I was under the impression that such was the case 
only in 2.0.8.


Thanks,
Sahoo

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

maven 2.0.7 reorders dependencies during build causing compilation failures

[Sahoo]

T.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/connectors/connectors-internal-api/3.0-SNAPSHOT/connectors-internal-api-3.0-SNAPSHOT.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/web/jsp-impl/2.1-SNAPSHOT/jsp-impl-2.1-SNAPSHOT.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/common/annotation-framework/3.0-SNAPSHOT/annotation-framework-3.0-SNAPSHOT.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/web/el-impl/1.1/el-impl-1.1.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/admin/target/classes 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/transaction/internal-api/target/classes 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/common/internal-api/target/classes 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/javax.servlet/target/classes 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/security/realms/3.0-SNAPSHOT/realms-3.0-SNAPSHOT.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/flashlight/framework/target/classes 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/distributions/external/asm-all/target/asm-all-repackaged-3.0-SNAPSHOT.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-core/target/classes 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/repository/org/glassfish/admin/cli-framework/3.0-SNAPSHOT/cli-framework-3.0-SNAPSHOT.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/javaee-api/javax.mail/target/javax.mail-3.0-SNAPSHOT.jar 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/distributions/external/grizzly-http/target/classes 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/core/kernel/target/classes 
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/javaee-api/javax.annotation/target/javax.annotation-3.0-SNAPSHOT.jar 
[DEBUG] Source roots:
[DEBUG]  http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/src/main/java 
[INFO] Compiling 130 source files to http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/target/classes 
Note: http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/src/main/java/com/sun/enterprise/web/WebComponentInvocation.java  uses or overrides a deprecated API.

Note: Recompile with -Xlint:deprecation for details.
http://hudson.sfbay/job/glassfish-v3-devbuild/ws/v3/web/web-glue/src/main/java/com/sun/enterprise/web/pwc/connector/coyote/PwcCoyoteRequest.java
 :146: cannot find symbol
symbol  : method getSessionCookieConfig()
location: interface javax.servlet.ServletContext
   (servletContext.getSessionCookieConfig()!=null)) {
  ^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Fatal error compiling



Is this not a bug?

Thanks,
Sahoo

[1] 
http://fisheye4.atlassian.com/browse/glassfish-svn/trunk/v3/web/web-glue/pom.xml?r=23482


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

Re: can't rev the version of multi-module project

[Sahoo]

I just want to say that this work around does not always work. It did 
not work for. See 
http://www.mail-archive.com/users@maven.apache.org/msg91071.html


Thanks,
Sahoo

Johan Lindquist wrote:

That rings a bell - and that would explain why it works for me - my root
pom (not the project root pom - declared a long while back) defines this
for the release plugin.  Apologies for the misleading post ...

Cheers,

Johan

Kalle Korhonen wrote:
  

Why don't you just run install during release:prepare?
http://maven.apache.org/plugins/maven-release-plugin/examples/run-goals-before-commit.html.
By default, install is not run (because it's not really released yet; but
typically causes issues with multi-module builds that use dependency plugin
or otherwise assumes the artifacts to be available)

Kalle

On Thu, Oct 16, 2008 at 1:10 PM, Ryan Heaton <[EMAIL PROTECTED]> wrote:



Thanks, that helps, but the build still fails on the install with the
same error because "child3" still depends on "child1" which isn't
installed yet.

However, this does somewhat simplify my procedure...

New procedure:

1. "mvn release:prepare" (build will fail with message described
below, but the pom versions will be updated)
2. for each module, in order: "mvn -N -DskipTests=true install"
3. "mvn release:clean" (clean up the last failed release)
4. "mvn release:prepare" (should work this time)
5. "mvn release:perform"

Again, if anyone can help simplify this process (especially step #2
above), please let me know.

Thanks,

-Ryan



On Thu, Oct 16, 2008 at 1:59 PM, Stephen Connolly
<[EMAIL PROTECTED]> wrote:
  

do mvn -N install in the parent folder first and then mvn install

2008/10/16 Ryan Heaton <[EMAIL PROTECTED]>:


Well, my show had to go on. I had to resort to revving, building and
deploying each module one-by-one.  Ouch!

If anyone can bring relief to my suffering, I would be greatly
  

appreciative.
  

-Ryan



On Wed, Oct 15, 2008 at 12:46 PM, Ryan Heaton <[EMAIL PROTECTED]>
  

wrote:
  

Hi.

I just converted my project to a Maven build.  I started with version
1.8-SNAPSHOT of my project and I'm trying to cut a release for version
1.8.

My project is quite complex: multi-module and modules have
dependencies on one another. So to make it simple, there's the parent
with 3 child modules: child1, child2, and child3. All children inherit
from the parent module.  child1 has no dependencies, child2 has a
dependency on child1 and child3 has a dependency on child2.

So, when I cut a release, all pom files are updated to the new
version, 1.8. The child poms, since they don't explicitly declare a
version, are updated to 1.8 by changing the inheritance of the parent
to version 1.8. The dependencies of the child poms are updated because
they're using a property reference, ${project.version}, to declare
their dependencies on their siblings.

But now I try to do a local install and get the "dependency can't be
resolved but has been found in the reactor" message and the build
fails because child3 can't resolve its dependency on child1 version
1.8.

Is my issue the same as http://jira.codehaus.org/browse/MNG-3685 ?

If so, how do I get Maven 2.0.11 installed? If not, how am I supposed
to cut a release? Is my project set up wrong?

Thanks in advance.

-Ryan



-
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: maven-release-plugin not able to locate extensions

[Sahoo]

Wendy Smoak wrote:

On Wed, Oct 15, 2008 at 3:50 AM, Sahoo <[EMAIL PROTECTED]> wrote:

  

As you can see, it uses a packaging type called distribution-fragment, which
is understood by our own extension called
org.glassfish.build:maven-glassfish-extension. We build the extension as
part of the same reactor.



Try configuring the release plugin to run all the way through
'install' rather than through 'integration-test' which is the default.

This isn't ideal, as you're building the artifact with the released
version in the filename _before_ the 'perform release' step, but there
are certain situations where it can't find things in the reactor.

  
First of all, thank you very much for taking the time to read my email 
and suggesting something. I tried your suggestion as shown below:
mvn -o release:prepare -DautoVersionSubmodules=true -DdryRun=true 
-DpreparationGoals="clean install"

, but it fails with same error.

Thanks,
Sahoo

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

[Help Required] [Fwd: maven-release-plugin not able to locate extensions]

[Sahoo]

Hi,

Appreciate any suggestion to solve this problem. I am stuck because of 
this issue.


Thanks,
Sahoo
--- Begin Message ---

Hi,

I am having problems using maven-release-plugin and I need some help 
urgently. While doing a release:prepare, maven is not able to locate an 
extension. I am using maven 2.0.7 on JDK 1.5. Given below are the 
essential details of the pom.xml that's facing the issue:

   
   org.glassfish.ejb
   ejb
   3.0-Prelude
   
   3.0-Prelude
   ejb-timer-databases
   distribution-fragment
   
   
   
   org.glassfish.build
   maven-glassfish-extension
   ${project.version}
   
   
   

As you can see, it uses a packaging type called distribution-fragment, 
which is understood by our own extension called 
org.glassfish.build:maven-glassfish-extension. We build the extension as 
part of the same reactor. For some other reason, we don't use 
true in our plugin configuration. I am able to 
do a normal build successfully, but when I am trying to prepare a 
release using maven-release-plugin, it fails with following error:



   [INFO] 


   [ERROR] BUILD ERROR
   [INFO] 


   [INFO] Failed to resolve artifact.
  
   Missing:

   --
   1) org.glassfish.build:maven-glassfish-extension:jar:3.0-Prelude
  
 Try downloading the file manually from the project website.
  
 Then, install it using the command:
 mvn install:install-file -DgroupId=org.glassfish.build 
-DartifactId=maven-glassfish-extension \

 -Dversion=3.0-Prelude -Dpackaging=jar -Dfile=/path/to/file
   Alternatively, if you host your own repository you can deploy 
the file there:   mvn deploy:deploy-file 
-DgroupId=org.glassfish.build -DartifactId=maven-glassfish-extension \
 -Dversion=3.0-Prelude -Dpackaging=jar 
-Dfile=/path/to/file \

  -Durl=[url] -DrepositoryId=[id]
  
 Path to dependency:
   1) 
org.glassfish.ejb:ejb-timer-databases:distribution-fragment:3.0-Prelude
   2) 
org.glassfish.build:maven-glassfish-extension:jar:3.0-Prelude
  
   --

   1 required artifact is missing.
  
   for artifact:
 
org.glassfish.ejb:ejb-timer-databases:distribution-fragment:3.0-Prelude


What is surprising is that it fails even when I have built the extension 
separately and installed it in my local repository. How can I avoid this 
error?


Thanks,
Sahoo

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


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

maven-release-plugin not able to locate extensions

[Sahoo]

Hi,

I am having problems using maven-release-plugin and I need some help 
urgently. While doing a release:prepare, maven is not able to locate an 
extension. I am using maven 2.0.7 on JDK 1.5. Given below are the 
essential details of the pom.xml that's facing the issue:

   
   org.glassfish.ejb
   ejb
   3.0-Prelude
   
   3.0-Prelude
   ejb-timer-databases
   distribution-fragment
   
   
   
   org.glassfish.build
   maven-glassfish-extension
   ${project.version}
   
   
   

As you can see, it uses a packaging type called distribution-fragment, 
which is understood by our own extension called 
org.glassfish.build:maven-glassfish-extension. We build the extension as 
part of the same reactor. For some other reason, we don't use 
true in our plugin configuration. I am able to 
do a normal build successfully, but when I am trying to prepare a 
release using maven-release-plugin, it fails with following error:



   [INFO] 


   [ERROR] BUILD ERROR
   [INFO] 


   [INFO] Failed to resolve artifact.
  
   Missing:

   --
   1) org.glassfish.build:maven-glassfish-extension:jar:3.0-Prelude
  
 Try downloading the file manually from the project website.
  
 Then, install it using the command:
 mvn install:install-file -DgroupId=org.glassfish.build 
-DartifactId=maven-glassfish-extension \

 -Dversion=3.0-Prelude -Dpackaging=jar -Dfile=/path/to/file
   Alternatively, if you host your own repository you can deploy 
the file there:   mvn deploy:deploy-file 
-DgroupId=org.glassfish.build -DartifactId=maven-glassfish-extension \
 -Dversion=3.0-Prelude -Dpackaging=jar 
-Dfile=/path/to/file \

  -Durl=[url] -DrepositoryId=[id]
  
 Path to dependency:
   1) 
org.glassfish.ejb:ejb-timer-databases:distribution-fragment:3.0-Prelude
   2) 
org.glassfish.build:maven-glassfish-extension:jar:3.0-Prelude
  
   --

   1 required artifact is missing.
  
   for artifact:
 
org.glassfish.ejb:ejb-timer-databases:distribution-fragment:3.0-Prelude


What is surprising is that it fails even when I have built the extension 
separately and installed it in my local repository. How can I avoid this 
error?


Thanks,
Sahoo

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

Re: [Fwd: true is ignored for maven-compiler-plugin]

[Sahoo]

I filed http://jira.codehaus.org/browse/MNG-3764.
As a work around, I am thinking of setting fork=true and passing 
-verbose as option to compiler.


Sahoo

Gabriel Garcia wrote:

Count me in for someone that wanted to compile with more verbosity
(e.g., to see warnings properly). The only thing that worked for me is
seeing the deprecated classes (which is another parameter). Other than
that, verbose=true didn't work.


Gabriel

2008/9/24 Sahoo <[EMAIL PROTECTED]>:
  

Has anyone experienced this problem?

I don't see the effect of true. When I run with -X, I do
see that verbose = true, but I don't see it being passed to javac. I tried
with fork = true and  the  command line that was used to invoke javac did
not have verbose option set. I am using default compiler.

Thanks,
Sahoo

-
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]

[Fwd: true is ignored for maven-compiler-plugin]

[Sahoo]

Has anyone experienced this problem?
--- Begin Message ---
I don't see the effect of true. When I run with -X, I 
do see that verbose = true, but I don't see it being passed to javac. I 
tried with fork = true and  the  command line that was used to invoke 
javac did not have verbose option set. I am using default compiler.


Thanks,
Sahoo

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


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

true is ignored for maven-compiler-plugin

[Sahoo]

I don't see the effect of true. When I run with -X, I 
do see that verbose = true, but I don't see it being passed to javac. I 
tried with fork = true and  the  command line that was used to invoke 
javac did not have verbose option set. I am using default compiler.


Thanks,
Sahoo

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

[Need Help] Re: jar artifact contains more classes than desired.

[Sahoo]

I have got closer to why it is happening. I wrote a small dtrace[1] 
script to monitor open system calls for those additional class files. I 
attached it to a build m/c and after around 150 builds, once it 
occurred. Every time open system call was made with that file handle, I 
print the java stack. The output of dtrace is attached here with. That 
file got opened three times. As the stack suggests, first by 
maven-compiler-plugin, then by maven-bundle-plugin and finally by 
maven-jar-plugin. So, it is the compiler-plugin that is responsible for 
creating that servlet class in jacc target dir. That is very surprising. 
*Why would compiler-plugin compile dependencies? *Any clue?


Thanks,
Sahoo

[1] http://opensolaris.org/os/community/dtrace/

Sahoo wrote:
We are experiencing an issue in our build system and it is not 
happening for every one. I used to think it only happens for mvn 
2.0.8, but just now a developer told me that they see it mvn 2.0.7 as 
well. For whatever reason, sometimes, a jar artifact is containing not 
only the classes compiled from the sources that are part of that 
artifact, it also contains dependent .class files. It is a very 
serious problem for us. Given below is the artifact that's causing 
trouble.


   4.0.0
   
   org.glassfish
   api-pom
   10.0-SNAPSHOT
   
   javax.security.jacc
   jar
   javax.security.jacc API v.1.2
   
   
   org.glassfish
   javax.servlet
   ${project.version}
   
  


As you can see, it depends on 
org.glassfish:javax.servlet:10.0-SNAPSHOT, which is a jar type 
artifact and contains javax.servlet classes. I can assure you that in 
the source tree of javax.security.jacc module, there is no 
javax.servlet class. Yet, javax.security.jacc-10.0-SNAPSHOT.jar 
contains a bunch of javax.servlet classes. I should also state that it 
only happens when both javax.servlet module and javax.security.jacc 
module are part of same maven reactor. The build log produced with -X 
option is quite large, so I am supplying log for jacc module portion 
only. Pl. see the attachment called build.all.jacc.log. I will be 
happy to supply more of it if need be. I should say, I don't 
understand something from the log file. I am highlighting it here with 
bold letters:


[INFO] Reactor build order:
...
[INFO]   javax.servlet API v.3.0
[INFO]   javax.security.jacc API v.1.2
...
[INFO] 


[INFO] Building javax.servlet API v.3.0
[INFO]task-segment: [clean, install]
[INFO] 


...
[INFO] Installing 
/export/v3/v3/web/javax.servlet/target/javax.servlet-10.0-SNAPSHOT-sources.jar 
to 
/home/mvatkina/.m2/repository/org/glassfish/javax.servlet/10.0-SNAPSHOT/javax.servlet-10.0-SNAPSHOT-sources.jar 

[INFO] 


[INFO] Building javax.security.jacc API v.1.2
[INFO]task-segment: [clean, install]
[INFO] 


...
[INFO] [clean:clean]
[INFO] Deleting directory 
/export/v3/v3/security/javax.security.jacc/target
[DEBUG] org.glassfish:javax.security.jacc:jar:10.0-SNAPSHOT (selected 
for null)

[DEBUG]   junit:junit:jar:4.3.1:test (selected for test)
[DEBUG]   active project artifact:
*artifact = 
org.glassfish:javax.servlet:jar:10.0-SNAPSHOT:compile;
   project: MavenProject: 
org.glassfish:javax.servlet:10.0-SNAPSHOT @ 
/export/v3/v3/web/javax.servlet/pom.xml (selected for compile)

*
What does this active project artifact mean? By looking at the 
attached log file, do you have any suggestion for me?


Thanks,
Sahoo

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

  0  94114 open64:entry 
  libc.so.1`__open64+0x15
  libc.so.1`open64+0x72
  libhpi.so`0xd0f2221b
  libjvm.so`JVM_Open+0x3a
  libjava.so`0xd0e9c3f0
  libjava.so`Java_java_io_FileOutputStream_open+0x2b
  java/io/FileOutputStream.open
  java/io/FileOutputStream.
  java/io/FileOutputStream.
  com/sun/tools/javac/jvm/ClassWriter.writeClass
  com/sun/tools/javac/main/JavaCompiler.genCode
  com/sun/tools/javac/main/JavaCompiler.compile
  com/sun/tools/javac/main/Main.compile
  com/sun/tools/javac/main/Main.compile
  com/sun/tools/javac/Main.compile
  StubRoutines (1)
  
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x187
  
libjvm.so`__1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v2468_v_+0x14
  

SNAPSHOT checked multiple times in same reactor?

[Sahoo]

In the same reactor build, does maven check SNAPSHOTs multiple times for 
the same artifact with same version? If yes, why does it do so?


Thanks,
Sahoo

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

Re: [Need Help] Why is maven trying to download files with different extension?

[Sahoo]

Stuart McCulloch wrote:


and perhaps also the  details of the artifact being downloaded
ie. does the  have bundle, or no  ?


  

Unfortunately, the dependencies are not published in any public repo
yet, otherwise I would have been able to provide the URL. How do I check
this detail? I looked at admin-cli-10.0-SNAPSHOT.pom in my local
repository and I do see it has bundle.




I was thinking more about the pom that is pulling down this
dependency - 
  
No, the dependant POM does not use . It specifies the dependency 
like this:

  
  org.glassfish.admin
  admin-cli
  ${glassfish.version}
  


Thanks,
Sahoo

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

[Need Help] Why is maven trying to download files with different extension?

[Sahoo]

I am seeing build failures, because maven is downloading files with 
.bundle extension as opposed to .jar as shown below:
Downloading 
http://download.java.net/maven/glassfish/org/glassfish/admin/admin-cli/10.0-SNAPSHOT/admin-cli-10.0-SNAPSHOT.bundle   



It is true the above artifact was produced by a plugin which uses custom 
packaging type called "bundle." But, why should that matter? Let me know 
if you want any further info. I need some help immediately.


Thanks,
Sahoo

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

Re: How to disable a plugin in a derived project?

[Sahoo]

Wendy Smoak wrote:

On Fri, Jun 27, 2008 at 4:32 PM, Sahoo <[EMAIL PROTECTED]> wrote:
  

I have the following scenario:
project B's pom.xml inherits from project A's pom.xml. A's pom.xml has
configured certain plugin to be executed as part of a project's life cycle.
I don't want the plugin to be active while building B. Is there a simple way
to disable that plugin in B's pom.xml? If yes, what is it? If no, why is
this facility not available to user?



Depending on what the plugin is and what does (specific examples are
better than A and B...) you might be able to override the
configuration in the child to skip execution,
AFAIK, this is plugin specific. Many plugins don't expose a simple way 
to be skipped.

 or set the the
 element to false so that it only executes in the parent
and not the child, or configure it to aggregate results.
  
Pardon my ignorance, but  needs to be set in the parent 
project, right? In that case, it actually disables the plugin in all the 
derived projects, which I don't want. I actually many derived projects 
(like B2,...,Bn) who wants the plugin to be executed; it's just that a 
particular Bi is not interested in it. I am wondering why there is not a 
simple way like false in child POM?


Thanks,
Sahoo

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

How to disable a plugin in a derived project?

[Sahoo]

I have the following scenario:
project B's pom.xml inherits from project A's pom.xml. A's pom.xml has 
configured certain plugin to be executed as part of a project's life 
cycle. I don't want the plugin to be active while building B. Is there a 
simple way to disable that plugin in B's pom.xml? If yes, what is it? If 
no, why is this facility not available to user?


Thanks,
Sahoo

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

Re: Is a version like 1.4.1-ea-SNAPSHOT considered SNAPSHOT version?

[Sahoo]

Simon,

Thanks for taking time to explain. Yes, I agree it's a bad practice to 
use -SNAPSHOT for binaries released to testing team.


What is a good use case for SNAPSHOT? I am still not convinced why 
x.y.z-ea-SNAPSHOT is bad, may be it's not clear in my mind yet. I was 
thinking the following is a fitting use case for using such a scheme:


Project version being developed: x.y.z
Next deliverable: "early access"
So, team decides to cut a branch called x.y.z-ea so that a small pool of 
developers work off that branch to produce a stable ea build while the 
majority of the developers continue off the x.y.z branch.
Let's say the team promotes binaries every week. Those builds are called 
x.y.z-ea-bN (N being a number). Between week N and N+1, the builds are 
likely to be called x.y.z-ea-bN-SNAPSHOT. Who needs these SNAPSHOTs? 
Typically developers of the project.


Do you agree, or would you call them something like 
x.y.z-bN-? If latter is the case, when would one use SNAPSHOT?


Thanks,
Sahoo

[EMAIL PROTECTED] wrote:

I think I have failed to make my point :-).

I would call them 1.2.3-ea1. Or 1.2.3-ea-mmdd.

Or use Wayne's approach of having normal version numbers that increment
each time any artifact is released outside the dev team, with some other
way of marking things as "stable" (eg odd vs even minor numbers, or -GA
for "general access" or similar).

In maven terminology, a SNAPSHOT artifact is something that can be
modified at any time, and that cannot (easily) be reproduced. This will
drive the test team crazy; they don't want the code changing while they
test it, and don't want to report bugs to a dev team which cannot
recreate the same binary to verify/debug against.

Forget about what the word "snapshot" means to you, or how it has been
used in the past in your company's vocabulary. Maven has a specific
meaning for that word that does not match the way you have used that
word in the past. Possibly maven's use is wrong ("-CURRENT" might have
been a better choice) but that's not configurable.

Regards,
Simon


Sahoo schrieb:
  

I think I have failed to make my point. If a project decides to cut an
"ea" branch for its next release 1.2.3 and post nightly binaries out
of that branch to testing teams, what would you call those binaries
as? I would call them 1.2.3-ea-SNAPSHOT.

Thanks,
Sahoo

[EMAIL PROTECTED] wrote:


I think there is some misunderstanding about the meaning of SNAPSHOT.

A snapshot is by definition an artifact that might be overwritten with a
new one. Therefore when you compile against a snapshot, you never know
whether you will get the same version you compiled against earlier or
not.

A "beta", "rc" or "ea" release is not a SNAPSHOT, because people
compiling against an rc or ea do NOT want to suddenly get a new version
when they compile. Instead they want to get a new version only when they
explicitly ask for one, and want the old file to remain unchanged.

So a "beta", "rc", "ea" etc. release is just a normal release with a
funny-looking version number. They should not have a -SNAPSHOT suffix on
the version.

Regards,
Simon

David Delbecq schrieb:
 
  

I think, as a manager of a project, when i see in the dependencies of
a projet :
1.4.1.25,
i just consider project depends on release 1.4.1.25. On the other
hand, if i see
1.4.2-rc4
my instinct tells me to check for 1.4.2 instead (for stability
purposes)


Now, a good question is, what's the point of having both ea and
SNAPSHOT tags in a version from the library user point of view :D
If user sees SNAPSHOT, he clearly know he is playing with instable yet
to change version ;)


En l'instant précis du 16/03/08 19:40, Wayne Fay s'exprimait en ces
termes:
   


You missed my point. I am asking you, what is the purpose of "early
access"? Can you not simply say "version 1.4.1.25 is the early access
build"?

I simply do not believe in using "early access" or "release candidate"
as components of the version tag itself. To me, these identifiers are
orthogonal to the versioning itself. I retain the right to be proven
otherwise.

Wayne

On 3/16/08, Sahoo <[EMAIL PROTECTED]> wrote:
 
 
  

How else would one qualify a build as "early access?" Let's think of
this hypothetical case:
if some project team decides to make the "early access" build as a
stable build, then how can they specify it? At some point of time,
they
would like to cut a branch in source code repository that's used to
development of "early access" build where as the main line is used
for
development of the final release. During such active development of
"early access" build, what version number can they use?

Thanks,
Sahoo

Wayne Fay wrote:
  


What&

Re: Is a version like 1.4.1-ea-SNAPSHOT considered SNAPSHOT version?

[Sahoo]

I think I have failed to make my point. If a project decides to cut an 
"ea" branch for its next release 1.2.3 and post nightly binaries out of 
that branch to testing teams, what would you call those binaries as? I 
would call them 1.2.3-ea-SNAPSHOT.


Thanks,
Sahoo

[EMAIL PROTECTED] wrote:

I think there is some misunderstanding about the meaning of SNAPSHOT.

A snapshot is by definition an artifact that might be overwritten with a
new one. Therefore when you compile against a snapshot, you never know
whether you will get the same version you compiled against earlier or not.

A "beta", "rc" or "ea" release is not a SNAPSHOT, because people
compiling against an rc or ea do NOT want to suddenly get a new version
when they compile. Instead they want to get a new version only when they
explicitly ask for one, and want the old file to remain unchanged.

So a "beta", "rc", "ea" etc. release is just a normal release with a
funny-looking version number. They should not have a -SNAPSHOT suffix on
the version.

Regards,
Simon

David Delbecq schrieb:
  

I think, as a manager of a project, when i see in the dependencies of
a projet :
1.4.1.25,
i just consider project depends on release 1.4.1.25. On the other
hand, if i see
1.4.2-rc4
my instinct tells me to check for 1.4.2 instead (for stability purposes)


Now, a good question is, what's the point of having both ea and
SNAPSHOT tags in a version from the library user point of view :D
If user sees SNAPSHOT, he clearly know he is playing with instable yet
to change version ;)


En l'instant précis du 16/03/08 19:40, Wayne Fay s'exprimait en ces
termes:


You missed my point. I am asking you, what is the purpose of "early
access"? Can you not simply say "version 1.4.1.25 is the early access
build"?

I simply do not believe in using "early access" or "release candidate"
as components of the version tag itself. To me, these identifiers are
orthogonal to the versioning itself. I retain the right to be proven
otherwise.

Wayne

On 3/16/08, Sahoo <[EMAIL PROTECTED]> wrote:
 
  

How else would one qualify a build as "early access?" Let's think of
this hypothetical case:
if some project team decides to make the "early access" build as a
stable build, then how can they specify it? At some point of time, they
would like to cut a branch in source code repository that's used to
development of "early access" build where as the main line is used for
development of the final release. During such active development of
"early access" build, what version number can they use?

Thanks,
Sahoo

Wayne Fay wrote:
   


What's the difference between 1.4.1-ea-SNAPSHOT and 1.4.1-SNAPSHOT?
That is, what is the actual utility of the "early access" tag?

Personally, I've always been dubious of these kinds of tags.

Wayne

On 3/16/08, Sahoo <[EMAIL PROTECTED]> wrote:

 
  

A/c to http://docs.codehaus.org/display/MAVEN/Versioning,
1.4.1-ea-SNAPSHOT results in a qualifier=ea-SNAPSHOT. Is this still
considered a SNAPSHOT? What I mean by that is, if a new binary is
posted
in repository, will maven still download it just like it does for a
SNAPSHOT version? If not, what's the best way to indicate "early
access
build" in a version string. I am using maven 2.0.7.

 
  




-
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 a version like 1.4.1-ea-SNAPSHOT considered SNAPSHOT version?

[Sahoo]

How else would one qualify a build as "early access?" Let's think of 
this hypothetical case:
if some project team decides to make the "early access" build as a 
stable build, then how can they specify it? At some point of time, they 
would like to cut a branch in source code repository that's used to 
development of "early access" build where as the main line is used for 
development of the final release. During such active development of 
"early access" build, what version number can they use?


Thanks,
Sahoo

Wayne Fay wrote:

What's the difference between 1.4.1-ea-SNAPSHOT and 1.4.1-SNAPSHOT?
That is, what is the actual utility of the "early access" tag?

Personally, I've always been dubious of these kinds of tags.

Wayne

On 3/16/08, Sahoo <[EMAIL PROTECTED]> wrote:
  

A/c to http://docs.codehaus.org/display/MAVEN/Versioning,
1.4.1-ea-SNAPSHOT results in a qualifier=ea-SNAPSHOT. Is this still
considered a SNAPSHOT? What I mean by that is, if a new binary is posted
in repository, will maven still download it just like it does for a
SNAPSHOT version? If not, what's the best way to indicate "early access
build" in a version string. I am using maven 2.0.7.

Thanks,
Sahoo

-
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: How to use maven-bundle-plugin for packaging type other than bundle or jar

[Sahoo]

Stuart McCulloch wrote:

Sahoo wrote:
Thank you, Stefan. That was it. It was my lack of knowledge of how to 
set List type of properties in pom.xml. I wish Maven could tell me 
that there is no configuration property called supportedProjectType 
in maven-bundle-plugin. Secondly, maven-bundle-plugin issues a DEBUG 
message if the project type is not suitable. If I run with -X option, 
I see a debug message that says project type is not compatible. I 
wish it were a WARNING from maven-bundle-plugin rather than a DEBUG 
message.

here's a wacky suggestion:  raise a change request for this on JIRA  ;)

  http://issues.apache.org/jira/browse/FELIX/component/12311143

seriously, the main drive is to fix issues reported on JIRA  -  if 
no-one reports anything then we typically fix things that itch us 
first...

DONE: https://issues.apache.org/jira/browse/FELIX-519

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

Is a version like 1.4.1-ea-SNAPSHOT considered SNAPSHOT version?

[Sahoo]

A/c to http://docs.codehaus.org/display/MAVEN/Versioning, 
1.4.1-ea-SNAPSHOT results in a qualifier=ea-SNAPSHOT. Is this still 
considered a SNAPSHOT? What I mean by that is, if a new binary is posted 
in repository, will maven still download it just like it does for a 
SNAPSHOT version? If not, what's the best way to indicate "early access 
build" in a version string. I am using maven 2.0.7.


Thanks,
Sahoo

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

Re: How to disable maven-compiler-plugin for jar packaging

[Sahoo]

Yes, your suggestion works, only thing is there is a slight modification 
needed. I had to write:

**/*.*
, otherwise mvn would complain that a String can't be assigned to a Set 
type.


Thanks,
Sahoo

VUB Stefan Seidel wrote:

Try




maven-compiler-plugin

**/*.*





or something similar.

Stefan

Sahoo wrote:

Hi,

I have an unusual requirement where I want to replace 
maven-compiler-plugin by another compiler-plugin. Is there a way I 
can do this? My situation is like this:
I want to use hk2-maven-plugin [1] as the compiler plugin. This 
plugin automatically executes if I change my project's packaging type 
to hk2-jar, but I don't want to change the project's packaging type 
from jar to hk2-jar, as I depend on some other plugin which stops 
working when I change my packaging type. If I just add an execution 
entry for hk2-maven-plugin:compile goal, it is useless as all the 
sources first get compiled using the default compiler-plugin. One 
option might be to call hk2-maven-plugin in a pre-compile phase, but 
is that the only option to disable the default plugin? I am looking 
for some ideas here.


Thanks,
Sahoo

[1]  https://hk2.dev.java.net/hk2-maven-plugin/hk2-compile-mojo.html

-
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: How to disable maven-compiler-plugin for jar packaging

[Sahoo]

I just learned that I was not configuring the other plugin correctly 
with the help I obtained from Felix users forum. So, my issue is resolved.


Thanks,
Sahoo

Sahoo wrote:
The other plugin that breaks is maven-bundle-plugin 
(http://felix.apache.org/site/maven-bundle-plugin-bnd.html). If you 
search their page, you shall find that it mentions it has 
supportedProjectTypes defaults to "jar","bundle."


Thanks,
Sahoo

Stephen Connolly wrote:
I think you are out of luck. What is the other plugin that breaks, 
and does

the hk2-jar packaging produce artifacts that have the type hk2-jar or do
they have the type jar?

I suspect that this bold 3rd plugin is expecting artifacts of type 
jar and

you are producing artifacts of type hk2-jar which is why it breaks.

I remember that there is a way to have the packaging xyz still 
produce only

artifact of type abc, and that using this removed the issue you describe
when I encountered it before

-Stephen

On Wed, Mar 12, 2008 at 8:46 AM, Sahoo <[EMAIL PROTECTED]> wrote:

 

Hi,

I have an unusual requirement where I want to replace
maven-compiler-plugin by another compiler-plugin. Is there a way I can
do this? My situation is like this:
I want to use hk2-maven-plugin [1] as the compiler plugin. This plugin
automatically executes if I change my project's packaging type to
hk2-jar, but I don't want to change the project's packaging type from
jar to hk2-jar, as I depend on some other plugin which stops working
when I change my packaging type. If I just add an execution entry for
hk2-maven-plugin:compile goal, it is useless as all the sources first
get compiled using the default compiler-plugin. One option might be to
call hk2-maven-plugin in a pre-compile phase, but is that the only
option to disable the default plugin? I am looking for some ideas here.

Thanks,
Sahoo

[1]  https://hk2.dev.java.net/hk2-maven-plugin/hk2-compile-mojo.html

-
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: How to use maven-bundle-plugin for packaging type other than bundle or jar

[Sahoo]

Thank you, Stefan. That was it. It was my lack of knowledge of how to 
set List type of properties in pom.xml. I wish Maven could tell me that 
there is no configuration property called supportedProjectType in 
maven-bundle-plugin. Secondly, maven-bundle-plugin issues a DEBUG 
message if the project type is not suitable. If I run with -X option, I 
see a debug message that says project type is not compatible. I wish it 
were a WARNING from maven-bundle-plugin rather than a DEBUG message.


Thanks, again.
Sahoo

VUB Stefan Seidel wrote:

The doc suggests

jar,bundle,hk2-jar
or maybe

  hk2-jar
  jar
  bundle


Stefan

Sahoo wrote:
I want to use maven-bundle-plugin in a project whose packaging type 
is neither jar nor bundle. Is it still possible? I configured my 
pom.xml like this, but it does not work:


   
   maven-jar-plugin
   
   
   
${project.build.outputDirectory}/META-INF/MANIFEST.MF 


   
   
   
   
   org.apache.felix
   maven-bundle-plugin
   
   hk2-jar
   jar
   bundle
   
   
   
   bundle-manifest
   process-classes
   
   manifest
   
   
   
   

Thanks,
Sahoo

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





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

Re: How to disable maven-compiler-plugin for jar packaging

[Sahoo]

The other plugin that breaks is maven-bundle-plugin 
(http://felix.apache.org/site/maven-bundle-plugin-bnd.html). If you 
search their page, you shall find that it mentions it has 
supportedProjectTypes defaults to "jar","bundle."


Thanks,
Sahoo

Stephen Connolly wrote:

I think you are out of luck. What is the other plugin that breaks, and does
the hk2-jar packaging produce artifacts that have the type hk2-jar or do
they have the type jar?

I suspect that this bold 3rd plugin is expecting artifacts of type jar and
you are producing artifacts of type hk2-jar which is why it breaks.

I remember that there is a way to have the packaging xyz still produce only
artifact of type abc, and that using this removed the issue you describe
when I encountered it before

-Stephen

On Wed, Mar 12, 2008 at 8:46 AM, Sahoo <[EMAIL PROTECTED]> wrote:

  

Hi,

I have an unusual requirement where I want to replace
maven-compiler-plugin by another compiler-plugin. Is there a way I can
do this? My situation is like this:
I want to use hk2-maven-plugin [1] as the compiler plugin. This plugin
automatically executes if I change my project's packaging type to
hk2-jar, but I don't want to change the project's packaging type from
jar to hk2-jar, as I depend on some other plugin which stops working
when I change my packaging type. If I just add an execution entry for
hk2-maven-plugin:compile goal, it is useless as all the sources first
get compiled using the default compiler-plugin. One option might be to
call hk2-maven-plugin in a pre-compile phase, but is that the only
option to disable the default plugin? I am looking for some ideas here.

Thanks,
Sahoo

[1]  https://hk2.dev.java.net/hk2-maven-plugin/hk2-compile-mojo.html

-
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]

How to use maven-bundle-plugin for packaging type other than bundle or jar

[Sahoo]

I want to use maven-bundle-plugin in a project whose packaging type is 
neither jar nor bundle. Is it still possible? I configured my pom.xml 
like this, but it does not work:


   
   maven-jar-plugin
   
   
   
${project.build.outputDirectory}/META-INF/MANIFEST.MF

   
   
   
   
   org.apache.felix
   maven-bundle-plugin
   
   hk2-jar
   jar
   bundle
   
   
   
   bundle-manifest
   process-classes
   
   manifest
   
   
   
   

Thanks,
Sahoo

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

How to disable maven-compiler-plugin for jar packaging

[Sahoo]

Hi,

I have an unusual requirement where I want to replace 
maven-compiler-plugin by another compiler-plugin. Is there a way I can 
do this? My situation is like this:
I want to use hk2-maven-plugin [1] as the compiler plugin. This plugin 
automatically executes if I change my project's packaging type to 
hk2-jar, but I don't want to change the project's packaging type from 
jar to hk2-jar, as I depend on some other plugin which stops working 
when I change my packaging type. If I just add an execution entry for 
hk2-maven-plugin:compile goal, it is useless as all the sources first 
get compiled using the default compiler-plugin. One option might be to 
call hk2-maven-plugin in a pre-compile phase, but is that the only 
option to disable the default plugin? I am looking for some ideas here.


Thanks,
Sahoo

[1]  https://hk2.dev.java.net/hk2-maven-plugin/hk2-compile-mojo.html

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

[Fwd: OutOfMemoryError during plugin execution, yet build continues!]

[Sahoo]

Has anyone encountered anything like this before? What is the fix?

Sahoo
--- Begin Message ---
I am seeing something very strange. We have our own plugin(it's 
basically an annotation processor) that gets invoked as part of compile 
phase. It appears that the JVM gets OutOfMemoryError when this plugin is 
executed, yet the build continues to the next phase instead of aborting. 
I ran with -X option and it shows that the plugin is invoked in process. 
I have looked at our plugin code and we do not catch Throwable or Error 
in our code. So, it appears to be a bug in Maven. Given below is some 
selected output that I think should give an idea of what's going on...


[INFO] 


[INFO] Building Web Container for GlassFish
[INFO]task-segment: [install]
[INFO] 


[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
...
[DEBUG] Configuring mojo 
'com.sun.enterprise:hk2-maven-plugin:0.2-SNAPSHOT:hk2-compile' -->

...
[DEBUG]   (f) fork = false
...
[INFO] [hk2:hk2-compile]
[DEBUG] Using compiler 'hk2-apt'.
[DEBUG] Source directories: 
[/space/ss141213/WS/gf/v3/web/webtier/src/main/java]

[DEBUG] Classpath: [/space/ss141213/WS/gf/v3/web/webtier/target/classes...
[INFO] Compiling 660 source files to 
/space/ss141213/WS/gf/v3/web/webtier/target/classes

The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: Java heap space
   at 
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
   at 
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)

   at java.lang.StringBuilder.append(StringBuilder.java:120)
   at com.sun.tools.javac.jvm.ClassReader.list(ClassReader.java:1756)
   at 
com.sun.tools.javac.jvm.ClassReader.listAll(ClassReader.java:1882)

   at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1901)
   at 
com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1538)

   at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
   at 
com.sun.tools.javac.jvm.ClassReader.completeOwners(ClassReader.java:1547)
   at 
com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1534)

   at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
   at 
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612)
   at 
com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550)
   at 
com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1440)

   at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482)
   at 
com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417)
   at 
com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1434)

   at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482)
   at 
com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417)

   at com.sun.tools.javac.code.Types.asSuper(Types.java:1407)
   at 
com.sun.tools.javac.code.Types$IsSubTypeFcn.visitClassType(Types.java:429)

   at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482)
   at 
com.sun.tools.javac.code.Types$IsSubTypeFcn.isSubType(Types.java:353)

   at com.sun.tools.javac.code.Types.isSubType(Types.java:331)
   at com.sun.tools.javac.code.Types.isSubTypeUnchecked(Types.java:311)
   at com.sun.tools.javac.code.Types.isConvertible(Types.java:278)
   at com.sun.tools.javac.code.Types.isAssignable(Types.java:1630)
   at com.sun.tools.javac.comp.Check.checkType(Check.java:325)
   at 
com.sun.tools.javac.comp.Annotate.enterAnnotation(Annotate.java:122)
   at 
com.sun.tools.javac.comp.MemberEnter.enterAnnotations(MemberEnter.java:705)

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
...

Thanks,
Sahoo

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


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

OutOfMemoryError during plugin execution, yet build continues!

[Sahoo]

I am seeing something very strange. We have our own plugin(it's 
basically an annotation processor) that gets invoked as part of compile 
phase. It appears that the JVM gets OutOfMemoryError when this plugin is 
executed, yet the build continues to the next phase instead of aborting. 
I ran with -X option and it shows that the plugin is invoked in process. 
I have looked at our plugin code and we do not catch Throwable or Error 
in our code. So, it appears to be a bug in Maven. Given below is some 
selected output that I think should give an idea of what's going on...


[INFO] 


[INFO] Building Web Container for GlassFish
[INFO]task-segment: [install]
[INFO] 


[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
...
[DEBUG] Configuring mojo 
'com.sun.enterprise:hk2-maven-plugin:0.2-SNAPSHOT:hk2-compile' -->

...
[DEBUG]   (f) fork = false
...
[INFO] [hk2:hk2-compile]
[DEBUG] Using compiler 'hk2-apt'.
[DEBUG] Source directories: 
[/space/ss141213/WS/gf/v3/web/webtier/src/main/java]

[DEBUG] Classpath: [/space/ss141213/WS/gf/v3/web/webtier/target/classes...
[INFO] Compiling 660 source files to 
/space/ss141213/WS/gf/v3/web/webtier/target/classes

The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: Java heap space
   at 
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
   at 
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)

   at java.lang.StringBuilder.append(StringBuilder.java:120)
   at com.sun.tools.javac.jvm.ClassReader.list(ClassReader.java:1756)
   at 
com.sun.tools.javac.jvm.ClassReader.listAll(ClassReader.java:1882)

   at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1901)
   at 
com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1538)

   at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
   at 
com.sun.tools.javac.jvm.ClassReader.completeOwners(ClassReader.java:1547)
   at 
com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1534)

   at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
   at 
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612)
   at 
com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550)
   at 
com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1440)

   at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482)
   at 
com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417)
   at 
com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1434)

   at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482)
   at 
com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417)

   at com.sun.tools.javac.code.Types.asSuper(Types.java:1407)
   at 
com.sun.tools.javac.code.Types$IsSubTypeFcn.visitClassType(Types.java:429)

   at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482)
   at 
com.sun.tools.javac.code.Types$IsSubTypeFcn.isSubType(Types.java:353)

   at com.sun.tools.javac.code.Types.isSubType(Types.java:331)
   at com.sun.tools.javac.code.Types.isSubTypeUnchecked(Types.java:311)
   at com.sun.tools.javac.code.Types.isConvertible(Types.java:278)
   at com.sun.tools.javac.code.Types.isAssignable(Types.java:1630)
   at com.sun.tools.javac.comp.Check.checkType(Check.java:325)
   at 
com.sun.tools.javac.comp.Annotate.enterAnnotation(Annotate.java:122)
   at 
com.sun.tools.javac.comp.MemberEnter.enterAnnotations(MemberEnter.java:705)

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
...

Thanks,
Sahoo

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

Re: Extending Maven2 plugins

[Sahoo]

See http://jira.codehaus.org/browse/MNG-3042 and 
http://jira.codehaus.org/browse/MPLUGIN-56. I hope they get fixed soon.


Thanks,
Sahoo

Rémy Sanlaville wrote:

Hi Julien,

I am not an expert but, what I understood, it is not possible to extend a
mojo for the moment.
Look at the archive of the mailing list maven-user and maven-dev. You will
find some post related to this question.

Rémy

  


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

Re: Maven Concepts

[Sahoo]

I am no maven expert. AFAIK, only if it is SNAPSHOT (the one that ends 
with -SNAPSHOT) version then maven checks the timestamp etc. against the 
remote repository. Otherwise Maven always prefers the one in the local 
repository if one is available there. In your case, the artifact version 
looks to be 1.0 which means once the artifact is available in your local 
repo, maven won't go to remote repo for that one. Question why did the 
owner of the artifact chose to update the artifact, but did not bother 
to change the version number?


Someone can correct me if need be.

Thanks,
Sahoo
amit kumar wrote:

Continuing on this thread I would also like to put a doubt(misconception)-
Until yesterday I used to think that if I have an artifact on local
repository + remote repository with same groupId-artifactId-version. The
maven will take the one which is built at a later time or some system
property attached to it which maven uses to differentiate.

The origin for this assumption was no matter if the artifact is present in
my local repository maven shows

Downloading \\remoteRepository\org\apache\x\x-1.0.pom
Downloading http:\\repo1.maven.org\org\apache\x\x-1.0.pom
.
.
.
.
.
What I assumed of this was that it compares where the latest of the artifact
is available even with same groupId+artifactId+version.

But yesterday when I cross checked even at the remote repository had a
artifact newly deployed (though with same groupId+artifactId+versionId) what
I was seeing in the classpath was the one from local repository.

Am I right in what I am concluding? Or again missing somewhere.

If what I have concluded upon is right, is there a way to make maven pick up
the one from remote repository(in case it is build and deployed later? )


Thanks and regards,
Amit


On Feb 8, 2008 4:55 AM, Graham Leggett <[EMAIL PROTECTED]> wrote:

  

Dhruva Reddy wrote:



What exactly is a goal and what is a phase?
  

In maven 1, there were only goals, and goals were specific targets that
were embedded in specific maven plugins, a bit like an ant target.

So the jar plugin would have the jar goal which when run, would jar up
some classes.

It soon became apparent that this leaves too much up to the end user:
what if the artifact you are producing isn't a jar, but an ear instead?
Or a war file? Why should the user have to know or care that they must
run the ear:ear goal instead of the jar:jar goal?

Enter the phases of the lifecycle in maven 2.

Plugins attach various goals to the various phases in the lifecycles,
and depending on which phase of the lifecycle you've asked maven to
complete, all the relevant goals attached to that lifecycle will be run
up to that phase.

So if you run "mvn install" (or "run all goals in all phases up until
the 'install' phase"), maven figures out for itself that the
compile:compile goal must run, and the ear:ear goal (because the
artifact is an ear file), the user no longer needs to care.

So to sum up:

The lifecycle contains a list of phases, and each phase has a goal or
goals attached to that phase. So running a phase is a convenient way of
saying "run all goals I need to run to make this artifact up to this
phase, and don't tell me what those goals are, I don't care".

Regards,
Graham
--




  


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

Why maven-compiler-plugin, source and target

[Sahoo]

When the philosophy of Maven is convention over configuration, why does 
maven-compiler-plugin require me to specify a target version every time 
I specify a source version. Can't it default the target version to be 
same as source version? Isn't it what most people do any way?


Thanks,
Sahoo

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

Re: Where is the version scheme in Maven documented?

[Sahoo]

Thank you. I had come across that doc as well, but I thought it was just 
a proposal. Why is it not part of some user manual? Once I was told not 
to go by the proposals, because the actual implementation might differ. 
Has it been fully implemented? If yes, in which release of maven?


Thanks,
Sahoo

Brian E. Fox wrote:

http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
+Resolution#DependencyMediationandConflictResolution-DependencyVersionRa
nges

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Sahoo
Sent: Sunday, January 13, 2008 2:45 AM
To: Maven Users List
Subject: Where is the version scheme in Maven documented?

Hi,

Where is the version scheme for Maven specified? I have found some links

[1,2,3] where it is briefly described, but none seems to be complete.

Thanks,
Sahoo

[1]
http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
[2] http://docs.codehaus.org/display/MAVEN/Versioning
[3] 
http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apac

he/maven/artifact/versioning/DefaultArtifactVersion.java?view=markup

-
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]

Where is the version scheme in Maven documented?

[Sahoo]

Hi,

Where is the version scheme for Maven specified? I have found some links 
[1,2,3] where it is briefly described, but none seems to be complete.


Thanks,
Sahoo

[1] http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
[2] http://docs.codehaus.org/display/MAVEN/Versioning
[3] 
http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java?view=markup


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

Re: No OSGi APIs in Maven repositories

[Sahoo]

Stuart McCulloch wrote:

On 13/01/2008, Sahoo <[EMAIL PROTECTED]> wrote:
  

I am sorry; I did not check correctly. I see them in m2 repository, but
the groupId is still org.apache.felix. Should such standard artifact not
be available with a vendor neutral groupId?




you mean like:

   http://repo1.maven.org/maven2/org/osgi

which contains the R4 core and compendium API artifacts...
  
  

Yes, that was what I was looking for. Thank you.

Sahoo

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

Re: No OSGi APIs in Maven repositories

[Sahoo]

I am sorry; I did not check correctly. I see them in m2 repository, but 
the groupId is still org.apache.felix. Should such standard artifact not 
be available with a vendor neutral groupId?


Thanks,
Sahoo

Sahoo wrote:

[posting to both felix and maven user forums]

Hi,

I don't seem to find OSGi API jars in standard Maven repositories. I 
find a version in 
http://people.apache.org/repo/m2-incubating-repository/ under the 
groupId org.apache.felix. But, I was expecting to find these standard 
APIs in the standard repository with a vendor neutral groupId & 
artifactId.


Thanks,
Sahoo

-
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]

No OSGi APIs in Maven repositories

[Sahoo]

[posting to both felix and maven user forums]

Hi,

I don't seem to find OSGi API jars in standard Maven repositories. I 
find a version in 
http://people.apache.org/repo/m2-incubating-repository/ under the 
groupId org.apache.felix. But, I was expecting to find these standard 
APIs in the standard repository with a vendor neutral groupId & artifactId.


Thanks,
Sahoo

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

Message from my annotation processor don't appear in console

[Sahoo]

Hi,

Recently I was writing an annotation processor [1]  which gets called 
from javac. JDK 6 javac exposes an API called Messager to be used to 
report warnings or errors or diagnostic information. I noticed that if I 
launch javac from command line, my messages appear in the output, but 
when javac is invcoked by maven-compiler-plugin, my messages don't 
appear. While debugging I found that maven passes StringWriter to javac 
to write the messages to and javac is also writing to that object, so I 
suspect maven is not subsequently printing the information available in 
the StringWriter object. More information is available at [2].


Thanks,
Sahoo

[1] 
http://weblogs.java.net/blog/ss141213/archive/2007/11/a_javac_plugin_1.html

[2] http://forum.java.sun.com/thread.jspa?threadID=5241006&tstart=0

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

Re: Not able to pass multiple arguments to javac

[Sahoo]

An improvement request is filed:
http://jira.codehaus.org/browse/MCOMPILER-62

Sahoo

Wayne Fay wrote:

I haven't looked at the code, but based on some historical emails on
this list it seemed like multiple  tags were the way
to go. One possible fix would be to take away the quoting of these
arguments, but I'm not sure if this wouldn't create some new
unintended side-effects.

It certainly sounds like this is something that could stand to be improved.

Wayne

On 11/26/07, Nick Stolwijk <[EMAIL PROTECTED]> wrote:
  

My first assumption was indeed wrong, because I used java 1.5 to check
for the existence of those properties. Also, your description (They are
not supported by javac.) set me on the wrong track. See my other mail
for the how and why of this error.

And indeed, in the current implementation, when you have multiple
"compilerArgument" elements only one is taken. I guess it just runs
setCompilerArgument multiple times.

With regards,

Nick Stolwijk

Sahoo wrote:


I doubt those message come from javac. They were printed by maven when
I ran it with -X option. Tell me what is the option that is *not*
supported by javac. AFAIK, all the options that I want to pass are
very much supported by javac. Check out the documentation [1] of javac
that comes with Sun JDK 6.

More over, JDK 6 compiler allows to provide plugins to javac. In order
to configure the plugin user may have to pass options that are *not*
meant for javac itself, instead they are meant for the javac plugin.
Such options will never be supported by maven-javac-plugin, hence
compilerArgument is the only way to use them. In case of Sun JDK, any
javac option starting -A is passed onto the plugin. An example is
available at [2]. I actually faced all my maven issues while
developing that plugin.

My observation is that when multiple compilerArgument is used, only
the last one is considered.

Thanks,
Sahoo

[1] http://java.sun.com/javase/6/docs/technotes/tools/solaris/javac.html
[2]

  

http://weblogs.java.net/blog/ss141213/archive/2007/11/a_javac_plugin_1.html


[EMAIL PROTECTED] wrote:
  

The fault message you see is actually from javac itself. You're
trying to add options that are not supported by javac. All javac
options are "supported" by the mojo, it simply passes them to javac.

Why would you want to add options to javac which are not supported by
javac?

With regards,

Nick Stolwijk


-Original Message-----
From: [EMAIL PROTECTED] on behalf of Sahoo
Sent: Mon 11/26/2007 5:12 PM
To: Maven Users List
Subject: Re: Not able to pass multiple arguments to javac

Yes, I knew that approach, but the options I actually want to pass
are not supported by the mojo. nowarn and verbose were just used as
examples; I want to pass -proc:none and -implicit. They are not
supported by javac. There are many such options which are not
supported by the mojo. I thought compilerArgument is the way to use
them. But, it is *not* working.

Thanks,
Sahoo

Jeff Jensen wrote:



Try this approach:


  true
  1024m
  true
  true
  etc...


To know element names to use, use the Name found in the Optional
Parameters
section of this page:

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



  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of



Sahoo

  

Sent: Monday, November 26, 2007 8:25 AM
To: Maven Users List
Subject: Re: Not able to pass multiple arguments to javac

Ignore my earlier email. The suggestion actually does *not* work.
When I
run with -X option, it shows only the last compilerArgument. See the
following output:

[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -->
[DEBUG]   (f) basedir = /tmp/my-app
[DEBUG]   (f) buildDirectory = /tmp/my-app/target
[DEBUG]   (f) classpathElements = [/tmp/my-app/target/classes]
[DEBUG]   (f) compileSourceRoots = [/tmp/my-app/src/main/java]
[DEBUG]   (f) compilerArgument = -verbose
[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true
[DEBUG]   (f) failOnError = true
[DEBUG]   (f) fork = false
[DEBUG]   (f) optimize = false
[DEBUG]   (f) outputDirectory = /tmp/my-app/target/classes
[DEBUG]   (f) outputFileName = my-app-1.0-SNAPSHOT
[DEBUG]   (f) projectArtifact =
com.mycompany.app:my-app:jar:1.0-SNAPSHOT
[DEBUG]   (f) showDeprecation = false
[DEBUG]   (f) showWarnings = false
[DEBUG]   (f) staleMillis = 0
[DEBUG]   (f) verbose = false
[DEBUG] -- end configuration --

Thanks,
Sahoo

Sahoo wrote:



Thanks, that works.

Sahoo

Wayne Fay wrote:

  

Try this, Sahoo:


   org.apache.maven.plugins
   maven-compiler-plugin
   
   -nowarn
   -verbose
   


On 11/22/07, Sahoo <[EMAIL PROTECTED]> wrote:




As suggested in [1], I tried configuring maven-compiler-plugin like
this:

 -nowarn

Re: Not able to pass multiple arguments to javac

[Sahoo]

I doubt those message come from javac. They were printed by maven when I 
ran it with -X option. Tell me what is the option that is *not* 
supported by javac. AFAIK, all the options that I want to pass are very 
much supported by javac. Check out the documentation [1] of javac that 
comes with Sun JDK 6.


More over, JDK 6 compiler allows to provide plugins to javac. In order 
to configure the plugin user may have to pass options that are *not* 
meant for javac itself, instead they are meant for the javac plugin. 
Such options will never be supported by maven-javac-plugin, hence 
compilerArgument is the only way to use them. In case of Sun JDK, any 
javac option starting -A is passed onto the plugin. An example is 
available at [2]. I actually faced all my maven issues while developing 
that plugin.


My observation is that when multiple compilerArgument is used, only the 
last one is considered.


Thanks,
Sahoo

[1] http://java.sun.com/javase/6/docs/technotes/tools/solaris/javac.html
[2] 
http://weblogs.java.net/blog/ss141213/archive/2007/11/a_javac_plugin_1.html

[EMAIL PROTECTED] wrote:

The fault message you see is actually from javac itself. You're trying to add options 
that are not supported by javac. All javac options are "supported" by the mojo, 
it simply passes them to javac.

Why would you want to add options to javac which are not supported by javac?

With regards,

Nick Stolwijk


-Original Message-
From: [EMAIL PROTECTED] on behalf of Sahoo
Sent: Mon 11/26/2007 5:12 PM
To: Maven Users List
Subject: Re: Not able to pass multiple arguments to javac
 
Yes, I knew that approach, but the options I actually want to pass are 
not supported by the mojo. nowarn and verbose were just used as 
examples; I want to pass -proc:none and -implicit. They are not 
supported by javac. There are many such options which are not supported 
by the mojo. I thought compilerArgument is the way to use them. But, it 
is *not* working.


Thanks,
Sahoo

Jeff Jensen wrote:
  

Try this approach:


  true
  1024m
  true
  true
  etc...


To know element names to use, use the Name found in the Optional Parameters
section of this page:
  http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html


  


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
    
  

Sahoo
  


Sent: Monday, November 26, 2007 8:25 AM
To: Maven Users List
Subject: Re: Not able to pass multiple arguments to javac

Ignore my earlier email. The suggestion actually does *not* work. When I
run with -X option, it shows only the last compilerArgument. See the
following output:

[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -->
[DEBUG]   (f) basedir = /tmp/my-app
[DEBUG]   (f) buildDirectory = /tmp/my-app/target
[DEBUG]   (f) classpathElements = [/tmp/my-app/target/classes]
[DEBUG]   (f) compileSourceRoots = [/tmp/my-app/src/main/java]
[DEBUG]   (f) compilerArgument = -verbose
[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true
[DEBUG]   (f) failOnError = true
[DEBUG]   (f) fork = false
[DEBUG]   (f) optimize = false
[DEBUG]   (f) outputDirectory = /tmp/my-app/target/classes
[DEBUG]   (f) outputFileName = my-app-1.0-SNAPSHOT
[DEBUG]   (f) projectArtifact = com.mycompany.app:my-app:jar:1.0-SNAPSHOT
[DEBUG]   (f) showDeprecation = false
[DEBUG]   (f) showWarnings = false
[DEBUG]   (f) staleMillis = 0
[DEBUG]   (f) verbose = false
[DEBUG] -- end configuration --

Thanks,
Sahoo

Sahoo wrote:

  

Thanks, that works.

Sahoo

Wayne Fay wrote:
  


Try this, Sahoo:


   org.apache.maven.plugins
   maven-compiler-plugin
   
   -nowarn
   -verbose
   


On 11/22/07, Sahoo <[EMAIL PROTECTED]> wrote:


  

As suggested in [1], I tried configuring maven-compiler-plugin like
this:

 -nowarn -verbose

But it causes compilation failure. Details given below:

Failure executing javac, but could not parse the error:
javac: invalid flag: -nowarn -verbose

How can I pass multiple arguments to javac?

Thanks,
Sahoo
[1]
http://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-
  


compiler-arguments.html

  

-
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 a

Re: Not able to pass multiple arguments to javac

[Sahoo]

Yes, I knew that approach, but the options I actually want to pass are 
not supported by the mojo. nowarn and verbose were just used as 
examples; I want to pass -proc:none and -implicit. They are not 
supported by javac. There are many such options which are not supported 
by the mojo. I thought compilerArgument is the way to use them. But, it 
is *not* working.


Thanks,
Sahoo

Jeff Jensen wrote:

Try this approach:


  true
  1024m
  true
  true
  etc...


To know element names to use, use the Name found in the Optional Parameters
section of this page:
  http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html


  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of


Sahoo
  

Sent: Monday, November 26, 2007 8:25 AM
To: Maven Users List
Subject: Re: Not able to pass multiple arguments to javac

Ignore my earlier email. The suggestion actually does *not* work. When I
run with -X option, it shows only the last compilerArgument. See the
following output:

[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -->
[DEBUG]   (f) basedir = /tmp/my-app
[DEBUG]   (f) buildDirectory = /tmp/my-app/target
[DEBUG]   (f) classpathElements = [/tmp/my-app/target/classes]
[DEBUG]   (f) compileSourceRoots = [/tmp/my-app/src/main/java]
[DEBUG]   (f) compilerArgument = -verbose
[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true
[DEBUG]   (f) failOnError = true
[DEBUG]   (f) fork = false
[DEBUG]   (f) optimize = false
[DEBUG]   (f) outputDirectory = /tmp/my-app/target/classes
[DEBUG]   (f) outputFileName = my-app-1.0-SNAPSHOT
[DEBUG]   (f) projectArtifact = com.mycompany.app:my-app:jar:1.0-SNAPSHOT
[DEBUG]   (f) showDeprecation = false
[DEBUG]   (f) showWarnings = false
[DEBUG]   (f) staleMillis = 0
[DEBUG]   (f) verbose = false
[DEBUG] -- end configuration --

Thanks,
Sahoo

Sahoo wrote:


Thanks, that works.

Sahoo

Wayne Fay wrote:
  

Try this, Sahoo:


   org.apache.maven.plugins
   maven-compiler-plugin
   
   -nowarn
   -verbose
   


On 11/22/07, Sahoo <[EMAIL PROTECTED]> wrote:



As suggested in [1], I tried configuring maven-compiler-plugin like
this:

 -nowarn -verbose

But it causes compilation failure. Details given below:

Failure executing javac, but could not parse the error:
javac: invalid flag: -nowarn -verbose

How can I pass multiple arguments to javac?

Thanks,
Sahoo
[1]
http://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-
  

compiler-arguments.html



-
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]

  


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

Re: Not able to pass multiple arguments to javac

[Sahoo]

Ignore my earlier email. The suggestion actually does *not* work. When I 
run with -X option, it shows only the last compilerArgument. See the 
following output:


[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -->

[DEBUG]   (f) basedir = /tmp/my-app
[DEBUG]   (f) buildDirectory = /tmp/my-app/target
[DEBUG]   (f) classpathElements = [/tmp/my-app/target/classes]
[DEBUG]   (f) compileSourceRoots = [/tmp/my-app/src/main/java]
[DEBUG]   (f) compilerArgument = -verbose
[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true
[DEBUG]   (f) failOnError = true
[DEBUG]   (f) fork = false
[DEBUG]   (f) optimize = false
[DEBUG]   (f) outputDirectory = /tmp/my-app/target/classes
[DEBUG]   (f) outputFileName = my-app-1.0-SNAPSHOT
[DEBUG]   (f) projectArtifact = com.mycompany.app:my-app:jar:1.0-SNAPSHOT
[DEBUG]   (f) showDeprecation = false
[DEBUG]   (f) showWarnings = false
[DEBUG]   (f) staleMillis = 0
[DEBUG]   (f) verbose = false
[DEBUG] -- end configuration --

Thanks,
Sahoo

Sahoo wrote:

Thanks, that works.

Sahoo

Wayne Fay wrote:

Try this, Sahoo:


   org.apache.maven.plugins
   maven-compiler-plugin
   
   -nowarn
   -verbose
   


On 11/22/07, Sahoo <[EMAIL PROTECTED]> wrote:
 
As suggested in [1], I tried configuring maven-compiler-plugin like 
this:


 -nowarn -verbose

But it causes compilation failure. Details given below:

Failure executing javac, but could not parse the error:
javac: invalid flag: -nowarn -verbose

How can I pass multiple arguments to javac?

Thanks,
Sahoo
[1]
http://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-compiler-arguments.html 




-
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: Not able to pass multiple arguments to javac

[Sahoo]

Thanks, that works.

Sahoo

Wayne Fay wrote:

Try this, Sahoo:


   org.apache.maven.plugins
   maven-compiler-plugin
   
   -nowarn
   -verbose
   


On 11/22/07, Sahoo <[EMAIL PROTECTED]> wrote:
  

As suggested in [1], I tried configuring maven-compiler-plugin like this:

 -nowarn -verbose

But it causes compilation failure. Details given below:

Failure executing javac, but could not parse the error:
javac: invalid flag: -nowarn -verbose

How can I pass multiple arguments to javac?

Thanks,
Sahoo
[1]
http://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-compiler-arguments.html


-
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]

Not able to pass multiple arguments to javac

[Sahoo]

As suggested in [1], I tried configuring maven-compiler-plugin like this:

 -nowarn -verbose

But it causes compilation failure. Details given below:

Failure executing javac, but could not parse the error:
javac: invalid flag: -nowarn -verbose

How can I pass multiple arguments to javac?

Thanks,
Sahoo
[1] 
http://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-compiler-arguments.html



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

[Fwd: Re: How to pass different options to javac during compile and testCompile goals?]

[Sahoo]

Any help?

Thanks,
Sahoo
--- Begin Message ---

Hi Milos,

Milos Kleint wrote:

Sahoo wrote:
(Resending as I am on the users alias now. I have also put a 
reference to a similar unsolved question from the past)


Hi,

I want to pass different options to maven-compiler-plugin during compile
and testCompile goals. Let's say, I want to set source level as 1.4 for
all my src/main/java code and set source level as 1.5 for my test
sources. How do I do it? I found someone having similar requirements 
in the past [1], but there is no mention of a working solution yet.


Thanks,
Sahoo

[1] 
http://mail-archives.apache.org/mod_mbox/maven-users/200609.mbox/[EMAIL PROTECTED] 






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


what about something like this?


  
  
  org.apache.maven.plugins
  maven-compiler
-plugin
  
 
${sourceLevel}

  ${sourceLevel}
  ${sourceLevel}
  
  
  
  compile-tests
  process-test-sources
  
  testCompile
  
  
 
${testSourceLevel}
 
${testSourceLevel}

  
  
  
  
  


  1.4
  1.5


Regards

Milos Kleint


Thanks for your timely response. Your suggestion seems to work, but I 
think there is something else which is contributing to the success here. 
*I see maven-compiler-plugin:testCompile goal is invoked twice*. The 
first time it uses our execution configuration, where as the second time 
around, it uses the default configuration. Since the test sources are 
already compiled during first execution, they are not compiled second 
time around. See the output below:


[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to /tmp/my-app/target/classes
[INFO] [compiler:testCompile {execution: compile-tests}]
[INFO] Compiling 1 source file to /tmp/my-app/target/test-classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]

Thanks,
Sahoo


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

Re: How to pass different options to javac during compile and testCompile goals?

[Sahoo]

Hi Milos,

Milos Kleint wrote:

Sahoo wrote:
(Resending as I am on the users alias now. I have also put a 
reference to a similar unsolved question from the past)


Hi,

I want to pass different options to maven-compiler-plugin during compile
and testCompile goals. Let's say, I want to set source level as 1.4 for
all my src/main/java code and set source level as 1.5 for my test
sources. How do I do it? I found someone having similar requirements 
in the past [1], but there is no mention of a working solution yet.


Thanks,
Sahoo

[1] 
http://mail-archives.apache.org/mod_mbox/maven-users/200609.mbox/[EMAIL PROTECTED] 






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


what about something like this?


  
  
  org.apache.maven.plugins
  maven-compiler
-plugin
  
 
${sourceLevel}

  ${sourceLevel}
  ${sourceLevel}
  
  
  
  compile-tests
  process-test-sources
  
  testCompile
  
  
 
${testSourceLevel}
 
${testSourceLevel}

  
  
  
  
  


  1.4
  1.5


Regards

Milos Kleint


Thanks for your timely response. Your suggestion seems to work, but I 
think there is something else which is contributing to the success here. 
*I see maven-compiler-plugin:testCompile goal is invoked twice*. The 
first time it uses our execution configuration, where as the second time 
around, it uses the default configuration. Since the test sources are 
already compiled during first execution, they are not compiled second 
time around. See the output below:


[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to /tmp/my-app/target/classes
[INFO] [compiler:testCompile {execution: compile-tests}]
[INFO] Compiling 1 source file to /tmp/my-app/target/test-classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]

Thanks,
Sahoo

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

How to pass different options to javac during compile and testCompile goals?

[Sahoo]

(I have not yet subscribed to users alias, so please copy a reply 
directly to me)


Hi,

I want to pass different options to maven-compiler-plugin during compile 
and testCompile goals. Let's say, I want to set source level as 1.4 for 
all my src/main/java code and set source level as 1.5 for my test 
sources. How do I do it?


Thanks,
Sahoo



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

How to pass different options to javac during compile and testCompile goals?

[Sahoo]

(Resending as I am on the users alias now. I have also put a reference 
to a similar unsolved question from the past)


Hi,

I want to pass different options to maven-compiler-plugin during compile
and testCompile goals. Let's say, I want to set source level as 1.4 for
all my src/main/java code and set source level as 1.5 for my test
sources. How do I do it? I found someone having similar requirements in 
the past [1], but there is no mention of a working solution yet.


Thanks,
Sahoo

[1] 
http://mail-archives.apache.org/mod_mbox/maven-users/200609.mbox/[EMAIL PROTECTED]





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

Re: JAXP DocumentBuilderFactory not found by maven-antrun-plugin initiated Ant

[Sahoo]

Hi Abe,

Thanks, that worked.
Why is it not able to load 
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl.class 
which is actually present in jre/lib/rt.jar? Is this a known bug in 
maven or ant? If yes, what's the bug number?


Thanks,
Sahoo

Developer Abe wrote:

Hi Sahoo,
 
I had a similar problem.
 
There are the dependecies that I had to provide to get rid of those 
exceptions:
 


xerces
xercesImpl
2.8.0


jdom
jdom
1.0


xml-apis
xml-apis
2.0.2

 
Also clean out your repository after adding these dependencies (delete 
the xerces, xml-apis, and jdom directories in your .m2 repository).
 
Let me know if this works for you.
 
Regards,

Abe

 
On 7/30/07, *Sahoo* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:


(I have not subscribed to users alias, so please copy a reply directly
to my email)

Hi,

I get /javax.xml.parsers.FactoryConfigurationError: Provider
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
could
not be instantiated: java.lang.NullPointerException/ when I call
an Ant
script from maven using maven-antrun-plugin. I have tried using
fork =
true as well as false, but same result. Maven version is 2.0.7 and JDK
version is 1.5.0_06. I don't understand why Ant is not finding this
class, which is actually present in jre/lib/rt.jar. I get the
following
output while running with -X option:

[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[DEBUG] getProperty(ns=null, name=ant.reuse.loader, user=false)
[DEBUG] getProperty(ns=null, name=ant.executor.class , user=false)
[DEBUG] getProperty(ns=null, name=ant.file, user=false)
test:
[echo] Generating Java classes from SDO Types
5  INFO   [main] openjpa.MetaData - Parsing XML Schema
"META-INF/po.xsd"
[java] javax.xml.parsers.FactoryConfigurationError: Provider
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
could
not be instantiated: java.lang.NullPointerException
[java] at
javax.xml.parsers.DocumentBuilderFactory.newInstance
(DocumentBuilderFactory.java:104)
[java] at

org.eclipse.xsd.util.DefaultJAXPConfiguration.createDocumentBuilder(DefaultJAXPConfiguration.java:94)
[java] at
org.eclipse.xsd.util.XSDResourceImpl.getDocument
(XSDResourceImpl.java:334)
[java] at
org.eclipse.xsd.util.XSDResourceImpl.getDocument(XSDResourceImpl.java:372)
[java] at
org.eclipse.xsd.util.XSDResourceImpl.doLoad (XSDResourceImpl.java:680)
[java] at
org.eclipse.xsd.util.XSDResourceImpl.load(XSDResourceImpl.java:617)
[java] at
org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:197)
[java] at
org.apache.tuscany.sdo.helper.XSDHelperImpl.define
(XSDHelperImpl.java:188)
[java] at

org.apache.openjpa.sdo.SDO2POJOGenerator.findTypes(SDO2POJOGenerator.java:126)
[java] at
org.apache.openjpa.sdo.SDO2POJOGenerator.run(SDO2POJOGenerator.java:246)

[java] at
org.apache.openjpa.sdo.SDO2POJOGenerator.main(SDO2POJOGenerator.java:282)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
[java] at

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java
:25)
[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:202)
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute
(ExecuteJava.java:134)
[java] at org.apache.tools.ant.taskdefs.Java.run
(Java.java:710)
[java] at
org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
[java] at org.apache.tools.ant.taskdefs.Java.execute
(Java.java:84)
[java] at
org.apache.tools.ant.UnknownElement.execute (UnknownElement.java:275)
[java] at org.apache.tools.ant.Task.perform(Task.java:364)
[java] at org.apache.tools.ant.Target.execute
(Target.java:341)
[java] at org.apache.tools.ant.Target.performTasks
(Target.java:369)
[java] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
[java] at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets
(SingleCheckExecutor.java :37)
[java] at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
[java] at
org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
[java] at
org.apache.

JAXP DocumentBuilderFactory not found by maven-antrun-plugin initiated Ant

[Sahoo]

  [java] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
[java] at 
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)

[java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
[java] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

[java] at java.lang.reflect.Method.invoke(Method.java:585)
[java] at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[java] at 
org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[java] at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

[java] at org.codehaus.classworlds.Launcher.main(Launcher.java:375)


Thanks,
Sahoo

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