Re: Advice on version control

[Ron Wheeler]

On 15/06/2010 9:04 AM, Eric Rotick wrote:

All good advice but my feeling is that is all comes down to one basic rule;
if it can go wrong, it will.

We've all been there; the code's written, the documentation's done and it's
just about to go out the door when someone spots something. The project lead
looks at it and decides it's a minor change and won't upset anything.
There's the problem. When the pressure is on, you make these silly mistakes.
If there was something that really did stop the re-release of a non snapshot
project then it has to be done by the book and the mistake avoided.

Even the additional work to bump other versions must be better than the
application failing. I know there will always be the occasion when the
change really is minor, like in say documentation and you could have gotten
away with it but I would certainly prefer that there was a 'machine' waiting
patiently to stop things like this in their tracks.

   
Someone with Nexus admin privs can delete a release and then you can 
re-release it.
Not a great thing to have happen but at least someone has to explicitly 
recognize that the release was bad and the new one is not.
They also have to explain to all the potential users that they have to 
delete the bad release from their local Maven cache.


Ron

I'm going to see if Nexus really is that quick to install. Of course, it's a
bit late now!
   

It is quick to install.



On Tue, Jun 15, 2010 at 1:52 PM, Jeff Jensen<
jeffjen...@upstairstechnology.com>  wrote:

   

And the release plugin does the version number changes (from snapshot to
release, commit POM, bump to next snapshot version, commit) for you...
I wonder if using it would help your process consistency by eliminating a
few manual things.


-Original Message-
From: Adrian Shum [mailto:tcs...@taifook.com]
Sent: Tuesday, June 15, 2010 7:42 AM
To: Maven Users List
Subject: RE: Advice on version control

I think the main point is: after release, change the POM version
immediately to
snapshot again.  By doing so, people shouldn't re-release accidentally
(They will only re-release a snapshot, which is harmless), unless they
explicitly
change the POM version and re-release themselves.

I think it is more of a procedure issue instead  :)

--
Best Regards,
AdRiAN ShUM


-Original Message-
From: Eric Rotick [mailto:pc.gree...@gmail.com]
Sent: Tuesday, June 15, 2010 7:53 PM
To: Maven Users List
Subject: Re: Advice on version control


This is exactly what we've been doing and it's been working well for
years but we now realise it's very fragile. The change that broke the
system was seemingly benign and the project lead also though so but in
reality it was not. If the policy of single releases only for non
snapshots was enforced then the other elements would have required a
minimum of a version bump and the system would still be fine.

I've often wondered why we needed a repo manager and now I know ;-)

On Tue, Jun 15, 2010 at 12:38 PM, Adrian Shum
wrote:

 

Here is the practice I am adopting now:

Whenever the project is open for change,
use SNAPSHOT version.

Change the version to a concrete version
number when you decide to perform a release.
Do your release branching and tagging etc,
and then immediate change the POM version
back to SNAPSHOT.

i.e. whenever a project source is subject to
change, use SNAPSHOT as version in POM

--
Best Regards,
AdRiAN ShUM


-Original Message-
From: Eric Rotick [mailto:pc.gree...@gmail.com]
Sent: Tuesday, June 15, 2010 7:22 PM
To: users@maven.apache.org
Subject: Advice on version control


This might be more to do with SCM than Maven but as Maven seems to
have the handle on most things I thought I'd ask this list first.

It is clear that the version contained in the pom is vitally important
   
 

and the process by which a version or revision number is incremented
is clear. Unfortunately, someone made a mistake of making a
significant change to some source and re-released the jars without
changing the version. The result was that the client application would
   
 

not talk to the server in certain conditions.

Basically, given our current procedures, this was a problem waiting to
   
 

happen.

Although it is clear what needs to happen it eludes us how this is
enforced. It seems that we need the ability to write snapshots any
number of times but non snapshots can only be written once and then no
   
 

more.

Hmm, I've just thought, maybe this is what the likes of Nexus and
Artifactory would do, but as you've probably guessed we don't use
anything like this.

Could anyone offer advice or practices to stop this happening again.

Thanks.

This email is confidential. If you are not the intended recipient,
please delete it from your system and notify the sender immediately.
Any unauthorized use, disclosure, dissemination or copying of this
email is prohibited. Taifook Securities Group, its group companies and
   
 

their content 

Re: Advice on version control

[Ron Wheeler]

On 15/06/2010 9:04 AM, Eric Rotick wrote:

All good advice but my feeling is that is all comes down to one basic rule;
if it can go wrong, it will.

   
Yes but it your systems should reduce the chance of it getting worse. A 
lot of cached releases in local Maven repos that are incorrect will 
cause a lot of chaos.



We've all been there; the code's written, the documentation's done and it's
just about to go out the door when someone spots something. The project lead
looks at it and decides it's a minor change and won't upset anything.
There's the problem. When the pressure is on, you make these silly mistakes.
If there was something that really did stop the re-release of a non snapshot
project then it has to be done by the book and the mistake avoided.

Even the additional work to bump other versions must be better than the
application failing. I know there will always be the occasion when the
change really is minor, like in say documentation and you could have gotten
away with it but I would certainly prefer that there was a 'machine' waiting
patiently to stop things like this in their tracks.

I'm going to see if Nexus really is that quick to install. Of course, it's a
bit late now!


On Tue, Jun 15, 2010 at 1:52 PM, Jeff Jensen<
jeffjen...@upstairstechnology.com>  wrote:

   

And the release plugin does the version number changes (from snapshot to
release, commit POM, bump to next snapshot version, commit) for you...
I wonder if using it would help your process consistency by eliminating a
few manual things.


-Original Message-
From: Adrian Shum [mailto:tcs...@taifook.com]
Sent: Tuesday, June 15, 2010 7:42 AM
To: Maven Users List
Subject: RE: Advice on version control

I think the main point is: after release, change the POM version
immediately to
snapshot again.  By doing so, people shouldn't re-release accidentally
(They will only re-release a snapshot, which is harmless), unless they
explicitly
change the POM version and re-release themselves.

I think it is more of a procedure issue instead  :)

--
Best Regards,
AdRiAN ShUM


-Original Message-
From: Eric Rotick [mailto:pc.gree...@gmail.com]
Sent: Tuesday, June 15, 2010 7:53 PM
To: Maven Users List
Subject: Re: Advice on version control


This is exactly what we've been doing and it's been working well for
years but we now realise it's very fragile. The change that broke the
system was seemingly benign and the project lead also though so but in
reality it was not. If the policy of single releases only for non
snapshots was enforced then the other elements would have required a
minimum of a version bump and the system would still be fine.

I've often wondered why we needed a repo manager and now I know ;-)

On Tue, Jun 15, 2010 at 12:38 PM, Adrian Shum
wrote:

 

Here is the practice I am adopting now:

Whenever the project is open for change,
use SNAPSHOT version.

Change the version to a concrete version
number when you decide to perform a release.
Do your release branching and tagging etc,
and then immediate change the POM version
back to SNAPSHOT.

i.e. whenever a project source is subject to
change, use SNAPSHOT as version in POM

--
Best Regards,
AdRiAN ShUM


-Original Message-
From: Eric Rotick [mailto:pc.gree...@gmail.com]
Sent: Tuesday, June 15, 2010 7:22 PM
To: users@maven.apache.org
Subject: Advice on version control


This might be more to do with SCM than Maven but as Maven seems to
have the handle on most things I thought I'd ask this list first.

It is clear that the version contained in the pom is vitally important
   
 

and the process by which a version or revision number is incremented
is clear. Unfortunately, someone made a mistake of making a
significant change to some source and re-released the jars without
changing the version. The result was that the client application would
   
 

not talk to the server in certain conditions.

Basically, given our current procedures, this was a problem waiting to
   
 

happen.

Although it is clear what needs to happen it eludes us how this is
enforced. It seems that we need the ability to write snapshots any
number of times but non snapshots can only be written once and then no
   
 

more.

Hmm, I've just thought, maybe this is what the likes of Nexus and
Artifactory would do, but as you've probably guessed we don't use
anything like this.

Could anyone offer advice or practices to stop this happening again.

Thanks.

This email is confidential. If you are not the intended recipient,
please delete it from your system and notify the sender immediately.
Any unauthorized use, disclosure, dissemination or copying of this
email is prohibited. Taifook Securities Group, its group companies and
   
 

their content providers ("Parties") shall not be responsible for the
accuracy or completeness of this email or its attachment, if any,
which could contain virus, be corrupted, destroyed, incomplete,
   

intercepted, lost 

RE: useStrictFiltering in assembly descriptor is broken

[Haszlakiewicz, Eric]

>>From: Haszlakiewicz, Eric [mailto:ehas...@transunion.com]
>>Sent: Thursday, June 03, 2010 12:26 PM
>>
>>I'm trying to turn on useStrictFiltering in a fileSet in an assembly
>>descriptor, but maven doesn't fail when the file does not exist.  Here

I just created a bug for this problem:
http://jira.codehaus.org/browse/MASSEMBLY-488

eric

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

RE: unpack-dependencies unpacks all dependencies

[GALLAGHER, RON (ATTSI)]

Eric,

The properties you should use are includeGroupIds [1] and
includeArtifactIds [2].  The POM file you provided does not pluralize
those properties.

[1]
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependenc
ies-mojo.html#excludeGroupIds
[2]
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependenc
ies-mojo.html#includeArtifactIds


Ron Gallagher


-Original Message-
From: Haszlakiewicz, Eric [mailto:ehas...@transunion.com] 
Sent: Wednesday, June 16, 2010 1:22 PM
To: Maven Users List
Subject: unpack-dependencies unpacks all dependencies


I'm having some problems making unpack-dependencies work right.  It
seems that no matter what I put for includeGroupId and includeArtifactId
it always unpacks all dependencies instead of only those that I want.

I was looking through jira to see if anyone else had this problem and
found something that looks like it might be related (although it only
talks about includeClassifiers):

http://jira.codehaus.org/browse/MDEP-257
That suggests to "Update the version [of maven-common-artifact-filters]
to current version 1.2 ... and you'll be fine".

So, I'm wondering how do I do that?  I tried removing my .m2 directory
to see if it would pick up a newer version, but I still end up with
version 1.0. (and only maven-dependency-plugin 2.0, even though it looks
like there's a 2.1 version available)
Alternately, am I doing something wrong with the unpack-dependencies
configuration?

At the end of this message is an example pom.xml file that demonstrates
the problem.  I am expecting this to only unpack the commons-beansutils
dependency, but it also unpacks commons-validator (and it's
dependencies).  I tried this with Maven 2.2.1.

Thanks,
eric


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
com.example
test
jar
1.0-SNAPSHOT
Test



commons-validator
commons-validator
1.3.1
provided


commons-beanutils
commons-beanutils
1.7.0
provided





   
 org.apache.maven.plugins
 maven-dependency-plugin
 
   
 unpack
 compile
 
   unpack-dependencies
 
 
  commons-beanutils
  commons-beanutils
 
${project.build.directory}/tempdir
 
   
 
   




-
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: Artifact in repo without an artifactId?

[Brett Porter]

I removed them so they can put the right things in place. To Maven, POMs that 
don't validate are equivalent to no POMs anyway. I kept the JARs in place 
despite them being removed in the source repository.

Yes, they should be using a system that checks for them instead of copying them 
blind.

- Brett

On 17/06/2010, at 6:26 AM, Wendy Smoak wrote:

> On Wed, Jun 16, 2010 at 3:54 PM, Stopp, Bryan
>  wrote:
>> I'm experiencing a strange issue and discrepancy with Maven 2.2.1 and
>> the m2eclipse plugin.
>> This artifact:
>> org.hsqldb:hsqldb-j5:2.0.0:jar
>> has a pom in repo1.maven.org which does not have a defined artifactId.
> 
> I'm going to guess it's related to
> http://jira.codehaus.org/browse/MAVENUPLOAD-2788
> 
> -- 
> Wendy
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





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

Re: Artifact in repo without an artifactId?

[Wendy Smoak]

On Wed, Jun 16, 2010 at 3:54 PM, Stopp, Bryan
 wrote:
> I'm experiencing a strange issue and discrepancy with Maven 2.2.1 and
> the m2eclipse plugin.
> This artifact:
> org.hsqldb:hsqldb-j5:2.0.0:jar
> has a pom in repo1.maven.org which does not have a defined artifactId.

I'm going to guess it's related to
http://jira.codehaus.org/browse/MAVENUPLOAD-2788

-- 
Wendy

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

Re: Artifact in repo without an artifactId?

[Wayne Fay]

> This artifact:
> org.hsqldb:hsqldb-j5:2.0.0:jar
> has a pom in repo1.maven.org which does not have a defined artifactId.

In all likelihood, this artifact did not come through a forge that
would have vetted the data but instead was merely rsync'ed with the
hsqdldb repo, or something. For reasons like this, the ability to
simply rsync with Central is going away.

I am opposed to changing things like this. Instead they should bump
the version to 2.0.1 or 2.0.0.1 and re-release it with the proper pom.

Wayne

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

Re: Artifact in repo without an artifactId?

[Anders Hammar]

Oh no... It seems to be a new artifact as well. I thought there were rules
in place that would prevent this from happening.
Could you please file a jira about this at
http://jira.codehaus.org/browse/MEV

/Anders

On Wed, Jun 16, 2010 at 21:54, Stopp, Bryan wrote:

> I'm experiencing a strange issue and discrepancy with Maven 2.2.1 and
> the m2eclipse plugin.
>
>
>
> This artifact:
>
>
>
> org.hsqldb:hsqldb-j5:2.0.0:jar
>
>
>
> has a pom in repo1.maven.org which does not have a defined artifactId.
>
>
>
> The m2eclipse plugin successfully resolves the artifact and downloaded
> it into my eclipse workspace. But when I go to build my application
> using the command I get this error:
>
>
>
> [ERROR] FATAL ERROR
>
> [INFO]
> 
>
> [INFO] An invalid artifact was detected.
>
>
>
> This artifact might be in your project's POM, or it might have been
> included transitively during the resolution process.
>
>  Here is the information we do have for this artifact:
>
>
>
>o GroupID: org.hsqldb
>
>o ArtifactID:  <<< MISSING >>>
>
>o Version: 2.0.0
>
>o Type:jar
>
>
>
> [INFO]
> 
>
> [INFO] Trace
>
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact
> {org.hsqldb:null:2.0.0:jar}: The artifactId cannot be
>
>  empty.
>
>
>
>
>
> How'd this happen to the pom.xml for this artifact? Is it a bug in
> m2eclipse that allows the artifact to be resolved, or is a bug in the
> command line maven that doesn't allow the resolution? Can someone fix
> the repository?
>
>
>
>
>
> -B
>
>
> PRIVILEGED AND CONFIDENTIAL
> This email transmission contains privileged and confidential information
> intended only for the use of the individual or entity named above.  If the
> reader of the email is not the intended recipient or the employee or agent
> responsible for delivering it to the intended recipient, you are hereby
> notified that any use, dissemination or copying of this email transmission
> is strictly prohibited by the sender.  If you have received this
> transmission in error, please delete the email and immediately notify the
> sender via the email return address or mailto:postmas...@argushealth.com.
>  Thank you.
>
>
>
>

Artifact in repo without an artifactId?

[Stopp, Bryan]

I'm experiencing a strange issue and discrepancy with Maven 2.2.1 and
the m2eclipse plugin.

 

This artifact:

 

org.hsqldb:hsqldb-j5:2.0.0:jar

 

has a pom in repo1.maven.org which does not have a defined artifactId.

 

The m2eclipse plugin successfully resolves the artifact and downloaded
it into my eclipse workspace. But when I go to build my application
using the command I get this error:

 

[ERROR] FATAL ERROR

[INFO]


[INFO] An invalid artifact was detected.

 

This artifact might be in your project's POM, or it might have been
included transitively during the resolution process.

 Here is the information we do have for this artifact:

 

o GroupID: org.hsqldb

o ArtifactID:  <<< MISSING >>>

o Version: 2.0.0

o Type:jar

 

[INFO]


[INFO] Trace

org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{org.hsqldb:null:2.0.0:jar}: The artifactId cannot be

 empty.

 

 

How'd this happen to the pom.xml for this artifact? Is it a bug in
m2eclipse that allows the artifact to be resolved, or is a bug in the
command line maven that doesn't allow the resolution? Can someone fix
the repository?

 

 

-B 


PRIVILEGED AND CONFIDENTIAL
This email transmission contains privileged and confidential information 
intended only for the use of the individual or entity named above.  If the 
reader of the email is not the intended recipient or the employee or agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any use, dissemination or copying of this email transmission is 
strictly prohibited by the sender.  If you have received this transmission in 
error, please delete the email and immediately notify the sender via the email 
return address or mailto:postmas...@argushealth.com.  Thank you.

Re: maven-eclipse-plugin and POM packaging projects

[Wayne Fay]

> Actually, m-e-p does not create any .project while M2Eclipse import both of
> them... and the multi-module is useless and I will just delete it.

IMO you are better off just switching over to m2eclipse full time
instead of continuing to fight with m-e-p.

Wayne

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

unpack-dependencies unpacks all dependencies

[Haszlakiewicz, Eric]

I'm having some problems making unpack-dependencies work right.  It
seems that no matter what I put for includeGroupId and includeArtifactId
it always unpacks all dependencies instead of only those that I want.

I was looking through jira to see if anyone else had this problem and
found something that looks like it might be related (although it only
talks about includeClassifiers):

http://jira.codehaus.org/browse/MDEP-257
That suggests to "Update the version [of maven-common-artifact-filters]
to current version 1.2 ... and you'll be fine".

So, I'm wondering how do I do that?  I tried removing my .m2 directory
to see if it would pick up a newer version, but I still end up with
version 1.0. (and only maven-dependency-plugin 2.0, even though it looks
like there's a 2.1 version available)
Alternately, am I doing something wrong with the unpack-dependencies
configuration?

At the end of this message is an example pom.xml file that demonstrates
the problem.  I am expecting this to only unpack the commons-beansutils
dependency, but it also unpacks commons-validator (and it's
dependencies).  I tried this with Maven 2.2.1.

Thanks,
eric


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
com.example
test
jar
1.0-SNAPSHOT
Test



commons-validator
commons-validator
1.3.1
provided


commons-beanutils
commons-beanutils
1.7.0
provided





   
 org.apache.maven.plugins
 maven-dependency-plugin
 
   
 unpack
 compile
 
   unpack-dependencies
 
 
  commons-beanutils
  commons-beanutils
 
${project.build.directory}/tempdir
 
   
 
   




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

Re: maven-eclipse-plugin and POM packaging projects

[Daniele Dellafiore]

Mixed feeling for me.

MultiModule pom project aren't to be imported as a project, I do agree.
But parent kind of pom project, I would like to see them imported. Problem
is that there is no way in maven to make a distinction.

Actually, m-e-p does not create any .project while M2Eclipse import both of
them... and the multi-module is useless and I will just delete it.

On Wed, Jun 16, 2010 at 5:14 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> On Tue, Jun 15, 2010 at 12:04 PM, Daniele Dellafiore 
> wrote:
> > I have "patched" maven-eclipse-plugin to create an eclipse project also
> for
> > projects with "pom" packaging type.
> > I was wondering if this was a bug or a feature and if someone is
> interested
> > in the plugin behaving this way other than me.
>
> I am glad the pom packaging projects don't generate .project files
> anymore. It was a drag with importing multimodule projects in eclipse.
> Far more easy to get all non-pom projects in one go, and just add the
> three pom type projects.
>
> My €0.02 (which isn't that much worth nowadays)
>
> Martijn
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Daniele Dellafiore
http://danieledellafiore.net

Re: maven-eclipse-plugin and POM packaging projects

[Martijn Dashorst]

On Tue, Jun 15, 2010 at 12:04 PM, Daniele Dellafiore  wrote:
> I have "patched" maven-eclipse-plugin to create an eclipse project also for
> projects with "pom" packaging type.
> I was wondering if this was a bug or a feature and if someone is interested
> in the plugin behaving this way other than me.

I am glad the pom packaging projects don't generate .project files
anymore. It was a drag with importing multimodule projects in eclipse.
Far more easy to get all non-pom projects in one go, and just add the
three pom type projects.

My €0.02 (which isn't that much worth nowadays)

Martijn

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

Re: using javascript dependencies in a webapp (war packaging)

[Shan Syed]

I'm considering moving my solution to using the concept of WAR overlays;
a WAR project that requires certain javascripts specifies those as project
dependencies, which themselves are simple WAR projects with only js files in
their correct paths

they get slapped onto the using WARs, and presto, no weirdness with copying
and unzipping directly

On Tue, Jun 15, 2010 at 6:23 PM, Haszlakiewicz, Eric  wrote:

> >-Original Message-
> >From: Shan Syed [mailto:shan...@gmail.com]
> >
> >I've worked on projects that share common javascript files, so I used a
> >simple assembly descriptor to zip each set of files and install them as
> >maven artifacts
> >WAR projects then just specified them as dependencies in their POMs
> >it's nice then to be able to treat these artifacts like any other
> project
> >(versioned, deployable to a repo, etc)
> >I used the maven-dependency plugin to unzip them to a standard folder
> >
> >we didn't require any parsing or compiling of the js, so this worked
> out
> >fine for simple packaging and unzipping
>
> I ended up doing something similar.  In case anyone else needs to do
> this in the future the steps I took were:
>  1) Create a jar file containing prototype-1.6.1.js at the top level
> [*1].  I also included a hand written README file in the META-INF
> directory with information about where the js file came from.
>  2) I deployed this to my local nexus repository as
> org.prototypejs:prototype:jar:1.6.1
>  3) I added the dependency to my webapp's pom.xml file with the
> "provided" scope.  That scope is needed to prevent the jar file from
> being included in the war.  (for some reason using "compile" scope
> didn't omit it)
>  4) I added the overlay configuration to the maven-war-plugin as
> described in my original message.  Since the README file is in the
> META-INF directory it doesn't get included.
>
> And now I get the js file extracted from the dependency jar file and
> included in the right place in the war file.
>
> This probably wouldn't work if prototypejs actually provided their own
> artifact, since the js file would probably be in a subdirectory, and
> there's no way to tell maven to rearrange things.
> However, in that case, I think I'd be able to use the maven-dependency
> plugin to unpack it to a temporary location, and then use some inline
> tasks in a maven-antrun-plugin to move the files to the right place.
> I've done this in other projects I've worked on and it's kind of
> annoying that maven doesn't support stuff like this natively, but at
> least it works.
>
> eric
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Provided-scoped dependencies and transitivity

[Jörg Schaible]

Hi Andreas,

Andreas Sewe wrote:

> Hi Jörg,
> 
> thanks for the quick reply.
> 
>>> According to the matrix in
>>> > mechanism.html#Dependency_Scope>
>>> a provided-scoped dependencies of a provided-scoped project dependency
>>> are themselves of scope provided (w.r.t. the project being built).
>>>
>>> The maven-dependency-plugin, however, disagrees. Both dependency:tree
>>> and dependency:copy-dependencies (with
>>> provided) ignore the transitive
>>> dependencies of my provided-scoped dependency. :-(
>>>
>>> So who's right: the documentation or the plugin?
>> 
>> The plugin.
> 
> Well, yes: In a sense, the code is always right, but what's the
> intuition behind the plugin's behavior? After all, if your project
> assumes that X is provided by the environment and X assumes the Y is
> provided by the environment, the environments should better provide both
> X and Y, right? Why ignore this information?

Well, "provided" deps have never been inherited transitively by any M2 
version. However, basically you're right, provided artifacts could be 
inherited again as provided, i.e. they are present at compile and runtime, 
but are not included into wars or ears (and the like). Currently you have to 
add these deps in derived jar artifacts over and over again and personally I 
am so used to this pattern, that I have not reflected this situation.

- Jörg


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

Re: Provided-scoped dependencies and transitivity

[Andreas Sewe]

Hi Jörg,

thanks for the quick reply.


According to the matrix in


a provided-scoped dependencies of a provided-scoped project dependency
are themselves of scope provided (w.r.t. the project being built).

The maven-dependency-plugin, however, disagrees. Both dependency:tree
and dependency:copy-dependencies (with
provided) ignore the transitive
dependencies of my provided-scoped dependency. :-(

So who's right: the documentation or the plugin?


The plugin.


Well, yes: In a sense, the code is always right, but what's the 
intuition behind the plugin's behavior? After all, if your project 
assumes that X is provided by the environment and X assumes the Y is 
provided by the environment, the environments should better provide both 
X and Y, right? Why ignore this information?


Best wishes,

Andreas

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

Re: Provided-scoped dependencies and transitivity

[Jörg Schaible]

Hi Andreas,

Andreas Sewe wrote:

> Hi all,
> 
> I have a hard time figuring out how provided-scoped dependencies
> interact with transitivity; either the documentation or the
> maven-dependency-plugin seem to get it wrong.
> 
> According to the matrix in
> 
> a provided-scoped dependencies of a provided-scoped project dependency
> are themselves of scope provided (w.r.t. the project being built).
> 
> The maven-dependency-plugin, however, disagrees. Both dependency:tree
> and dependency:copy-dependencies (with
> provided) ignore the transitive
> dependencies of my provided-scoped dependency. :-(
> 
> So who's right: the documentation or the plugin?

The plugin.


- Jörg


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

Provided-scoped dependencies and transitivity

[Andreas Sewe]

Hi all,

I have a hard time figuring out how provided-scoped dependencies 
interact with transitivity; either the documentation or the 
maven-dependency-plugin seem to get it wrong.


According to the matrix in 
 
a provided-scoped dependencies of a provided-scoped project dependency 
are themselves of scope provided (w.r.t. the project being built).


The maven-dependency-plugin, however, disagrees. Both dependency:tree 
and dependency:copy-dependencies (with 
provided) ignore the transitive 
dependencies of my provided-scoped dependency. :-(


So who's right: the documentation or the plugin?

Best wishes,

Andreas Sewe

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