Re: Revert Releases usigng Versions Plugin

[Aliaksei Lahachou]

Don't forget that once released artifact is downloaded to the local
repository, Maven will not try to download it again, because it is assumed
that released artifacts never change.

Just my 0.02 €.

Regards,
htfv (Aliaksei Lahachou)
 Am 18.07.2012 04:30 schrieb "Wayne Fay" :

> > The Real Challenge we face is when we decide to Revert/Roll-back from a
> > Release, we currently delete Artifacts from Nexus, delete tags etc which
> is
> > cumbersome.
> >
> > Wondering if there is an easy way out  Reverting/Roll-back Releases using
> > this Plugin or Kindly suggest any other easier way.
>
> As Manfred already said, simply don't ever revert/roll-back, but
> rather bump/roll the version forward by 0.0.1 and keep truckin'.
>
> Reverting is dangerous. You don't know "which" version 1.0.3 of an
> artifact is installed in any given Maven repo or repo cache, and
> things get awful messy in a short period of time. Don't go down this
> path.
>
> Wayne
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: BUILD FAILURE to create project structure

[Barrie Treloar]

On Wed, Jul 18, 2012 at 11:57 AM, Wayne Fay  wrote:
>> can please explain me the way how to create project structure/whole project
>> outside the bin folder of maven ??

Have you tried one of the freely available books at
http://maven.apache.org/articles.html?
Some of these should walk through examples of installing maven and
trying something out.

Also read http://maven.apache.org/users/index.html and the "5 minute test"

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

Re: Revert Releases usigng Versions Plugin

[Wayne Fay]

> The Real Challenge we face is when we decide to Revert/Roll-back from a
> Release, we currently delete Artifacts from Nexus, delete tags etc which is
> cumbersome.
>
> Wondering if there is an easy way out  Reverting/Roll-back Releases using
> this Plugin or Kindly suggest any other easier way.

As Manfred already said, simply don't ever revert/roll-back, but
rather bump/roll the version forward by 0.0.1 and keep truckin'.

Reverting is dangerous. You don't know "which" version 1.0.3 of an
artifact is installed in any given Maven repo or repo cache, and
things get awful messy in a short period of time. Don't go down this
path.

Wayne

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

Re: BUILD FAILURE to create project structure

[Wayne Fay]

> can please explain me the way how to create project structure/whole project
> outside the bin folder of maven ??

First make sure "mvn -v" runs and outputs the proper information.
Until this is working properly, there is no point to proceed.

Make a new directory say c:\code.
cd to that directory.
Type "mvn archetype:generate" or whatever and build the project there.

If that isn't what you are asking, please ask more specific questions
and/or provide examples of what end results you desire.

Wayne

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

Re: Revert Releases usigng Versions Plugin

[Manfred Moser]

On Tue, July 17, 2012 4:40 pm, krishna chaitanya kurnala wrote:
> Hello All
>
> We are tryign to use Maven Versions Plugin(
> http://mojo.codehaus.org/versions-maven-plugin/ ) as a automated way to
> keep diff module versions in sync in our POM's.
>
> The Real Challenge we face is when we decide to Revert/Roll-back from a
> Release, we currently delete Artifacts from Nexus, delete tags etc which
> is
> cumbersome.
>
> Wondering if there is an easy way out  Reverting/Roll-back Releases using
> this Plugin or Kindly suggest any other easier way.

I would suggest not to roll back at all but rather cut a new release
taking advantage of the fact that version numbers are cheap ;-) or get
Nexus Professional and use the staging suite to help you with your release
process.

Manfred
http://simpligility.com

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

Revert Releases usigng Versions Plugin

[krishna chaitanya kurnala]

Hello All

We are tryign to use Maven Versions Plugin(
http://mojo.codehaus.org/versions-maven-plugin/ ) as a automated way to
keep diff module versions in sync in our POM's.

The Real Challenge we face is when we decide to Revert/Roll-back from a
Release, we currently delete Artifacts from Nexus, delete tags etc which is
cumbersome.

Wondering if there is an easy way out  Reverting/Roll-back Releases using
this Plugin or Kindly suggest any other easier way.

thanks,
Krishna Kurnala

[ANN] gwt-maven-plugin 2.5.0-rc1 Released

[Thomas Broyer]

Hi,

I'm pleased to announce the release of the gwt-maven-plugin version 2.5.0-rc1.

http://mojo.codehaus.org/gwt-maven-plugin/

To get this update, simply specify the version in your project's
plugin configuration:


org.codehaus.mojo
gwt-maven-plugin
2.5.0-rc1


Release Notes

http://mojo.codehaus.org/gwt-maven-plugin/whats_new.html


Enjoy,


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

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

Re: BUILD FAILURE to create project structure

[rahul bhalla]

hi
As you said i do and now it its running
*thanks for the help*
can please explain me the way how to create project structure/whole project
outside the bin folder of maven ??
-- 
Regards
Rahul Bhalla

Re: problem in installing/running maven

[Dennis Lundberg]

Hi

Please run the command SET in a command window and paste the relevant
parts here, i.e. M2_HOME, M2, JAVA_HOME and PATH.

On 2012-07-17 22:01, rahul bhalla wrote:
> hi
> I new to maven project and first time i to runand install maven
> I followed the following steps which instruct by apache maven
> 
>1. Add the M2_HOME environment variable by opening up the system
>properties (WinKey + Pause), selecting the "Advanced" tab, and the
>"Environment Variables" button, then adding the M2_HOME variable in the
>user variables with the value *C:\Program Files\apache-maven-3.0.4*
>2. In the same dialog, add the M2 environment variable in the user
>variables with the value %M2_HOME%\bin.
>3. In the same dialog, update/create the Path environment variable in
>the user variables and prepend the value %M2% to add Maven available in
>the command line.
>4. In the same dialog, make JAVA_HOME in user variables  with the
> value C:\Program
>Files\Java\jdk1.6.0_21 and that %JAVA_HOME%\bin is in your Path environment
>variable.
>5. Open a *new* command prompt (Winkey + R then type cmd) and run mvn
>--version to verify that it is correctly installed.
> 
> *C:\Users\sahil>mvn --version*
> 'mvn' is not recognized as an internal or external command,
> operable program or batch file
> 
> if the directory is changes to* C:\Program Files\apache-maven-3.0.4\bin>*
> then it runs .
> 
> now please tell me what is problem when i try to issue a command  from *
> C:\Users\sahil>* directory
> 


-- 
Dennis Lundberg



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

Re: problem in installing/running maven

[Wayne Fay]

> *C:\Users\sahil>mvn --version*
> 'mvn' is not recognized as an internal or external command,
> operable program or batch file
>
> if the directory is changes to* C:\Program Files\apache-maven-3.0.4\bin>*
> then it runs .

Please do not install Maven (or really anything) under Program Files,
or any other directory with a space in it. Spaces in directory names
can and will make your life more difficult.

Make a c:\dev or c:\code or c:\projects, really anything, and install
there. Then try to follow the instructions again and see if it works.

Wayne

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

BUILD FAILURE to create project structure

[rahul bhalla]

hi
i new to maven and try to create project structure with help of maven. I m
using Maven 3.0.4 version

Every time i try to run given command* C:\Program
Files\apache-maven-3.0.4\bin>mvn archetype:generate*
it ask :

   - Choose a number or apply filter (format: [groupId:]artifactId, case
   sensitive contains): 205: 596

   Choose org.springframework.osgi:spring-osgi-bundle-archetype
version:
   1: 1.0
   2: 1.0.1
   3: 1.0.2
   4: 1.0.3
   5: 1.1.0
   6: 1.1.1
   7: 1.1.2
   8: 1.1.3
   9: 1.2.0
   10: 1.2.1
   Choose a number: 10: 10
   Define value for property 'groupId': : com.rahul
   Define value for property 'artifactId': : gallery
   Define value for property 'version':  1.0-SNAPSHOT: :
   Define value for property 'package':  com.rahul: :
   Confirm properties configuration:
   groupId: com.rahul
   artifactId: gallery
   version: 1.0-SNAPSHOT
   package: com.rahul
Y: : y
[INFO]

[INFO] Using following parameters for creating project from Old (1.x)
Archetype: spring-osgi-bundle-archetype:1.2.1
[INFO]

[INFO] Parameter: groupId, Value: com.rahul
[INFO] Parameter: packageName, Value: com.rahul
[INFO] Parameter: package, Value: com.rahul
[INFO] Parameter: artifactId, Value: gallery
[INFO] Parameter: basedir, Value: C:\Program Files\apache-maven-3.0.4\bin
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 1:53.783s
[INFO] Finished at: Wed Jul 18 01:34:34 IST 2012
[INFO] Final Memory: 7M/17M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli)
on project standalone-pom: Error merging velocity templates -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException



please help me solve above issue
thanking you
-- 
Regards
Rahul Bhalla

Re: Duplicate dependency with different scopes

[Anders Hammar]

I believe what happens here is that the dependency declared closest to
your project wins. But you can control this through
dependencyManagement in your project.

/Anders

On Tue, Jul 17, 2012 at 5:06 PM, Graham Crosmarie
 wrote:
> A defines a dependency on D with scope test and is a pom project
>
> B defines a dependency on D with compile (default) and is a jar project.
> A is the parent pom of B.
> When I run dependency:tree I get what I want for B : D with scope compile.
>
> I have other projects (C) whose parent is A and which depend on B with scope
> compile(default).
> My problem is that the D dependency for such projects is in scope test
> (inherited from A) instead of scope compile (retrieved through the
> dependency on B).
>
> In other words Maven chooses the wrong scope for my C projects. In fact, I
> think it always takes the one from the before parent and ignores the one
> from the dependency.
>
>
> On 17/07/2012 15:29, Aliaksei Lahachou wrote:
>>
>> Hi!
>>
>> In parent A, so you define scope in dependency or dependency management
>> section. If the latter, then it overrides scope of the transitive
>> dependency.
>>
>> In which scope is dependency B? If it's in test scope, than its
>> dependencies will be in test scope, too.
>>
>> It would be much easier if you could show the POMs.
>>
>> Regards,
>> htfv (Aliaksei Lahachou)
>> Am 17.07.2012 09:15 schrieb "Graham Crosmarie" <
>> graham.crosma...@linagora.com>:
>>
>>> Hello,
>>>
>>> I have a problem with my dependency pattern and I am not sure that maven
>>> behaves correctly in this case.
>>>
>>> Here is my case :
>>>  - I am using Maven 2.2.1.
>>>  - I have a project A which defines a dependency D with scope test.
>>>  - I have a project B whose parent is A and which defines D as a
>>> dependency in scope compile.
>>>  - My project hierarchy defines a lot of projects whose parent is A
>>> and
>>> who have B as a dependency.
>>>
>>> My problem is : all these "subprojects" have D as dependency in scope
>>> test
>>> (from A).
>>> I think that the correct behaviour would be to have D with scope compile
>>> (from their dependency on B) because scope compile 'contains' scope test.
>>> But Maven 2.2.1 does not work that way :-).
>>>
>>> Is there any way to force my projects to use the D scope from project B
>>> instead of the one from its parent (project A) ?
>>>
>>> Thanks in avance,
>>>
>>> --
>>> Signature
>>> Graham CROSMARIE
>>> R&D Engineer
>>> Linagora GSO -- www.linagora.com 
>>>
>
>
> --
> Signature
> Graham CROSMARIE
> R&D Engineer
> Linagora GSO -- www.linagora.com 

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

problem in installing/running maven

[rahul bhalla]

hi
I new to maven project and first time i to runand install maven
I followed the following steps which instruct by apache maven

   1. Add the M2_HOME environment variable by opening up the system
   properties (WinKey + Pause), selecting the "Advanced" tab, and the
   "Environment Variables" button, then adding the M2_HOME variable in the
   user variables with the value *C:\Program Files\apache-maven-3.0.4*
   2. In the same dialog, add the M2 environment variable in the user
   variables with the value %M2_HOME%\bin.
   3. In the same dialog, update/create the Path environment variable in
   the user variables and prepend the value %M2% to add Maven available in
   the command line.
   4. In the same dialog, make JAVA_HOME in user variables  with the
value C:\Program
   Files\Java\jdk1.6.0_21 and that %JAVA_HOME%\bin is in your Path environment
   variable.
   5. Open a *new* command prompt (Winkey + R then type cmd) and run mvn
   --version to verify that it is correctly installed.

*C:\Users\sahil>mvn --version*
'mvn' is not recognized as an internal or external command,
operable program or batch file

if the directory is changes to* C:\Program Files\apache-maven-3.0.4\bin>*
then it runs .

now please tell me what is problem when i try to issue a command  from *
C:\Users\sahil>* directory
-- 
Regards
Rahul Bhalla
(9953225211)

Re: OT: Re: Issue-wise Crowdfunding platform for Maven

[Benson Margulies]

It is extremely unlikely that the Foundation will be interested in any
participation except to gratefully accept any unrestricted donations
your organization might happen to make. If you want to state on your
website that you are going to donate something to the ASF when the
issue is an ASF project JIRA, and you conform the ASF trademark and
branding guidelines, I predict (speaking without wearing any official
ASF hat) that all will be well.

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

Managing alternate source types to Java/Script/Resource across pluggins

[GregDomjan]

I'm looking at Native compilation, particularly with NAR and want to make
some other extensions that will add sources for NAR to compile - if it is
being used already.  For instance XSD code generation like XMLBeans.

For Java the MavenProject provides access to the
CompileSourceRoots/TestCompileSourceRoots adding across plugins.

NAR also goes through these locations to potentially add files to compile (I
think it should not because it adds for all native types) 

Is there some appropriate location to do the same for Extension Plugins for
alternate file types?
I've had a look around extending MavenProject, Build/BuildOverlay and this
just doesn't seem right.

It seems like MavenProject.getBuildExtensions might be a way to go, the
other projects needing to depend on NAR seems a bit heavy at the moment.

--
View this message in context: 
http://maven.40175.n5.nabble.com/Managing-alternate-source-types-to-Java-Script-Resource-across-pluggins-tp5714310.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

Re: best practices

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
THere are many dependencies using that one as a transitive, so I don't
want to be in a situation when I would forget to exclude them.
Changing a version using dependency management works for all.

W dniu 2012-07-17 16:40, Ron Wheeler pisze:
> Sometimes a best practice requires you to do things that you don't want to do 
> for short term reasons.
>
> Why not add an exclusion for stuff you want Maven to exclude?
>
> Ron
>
> On 17/07/2012 10:02 AM, Michał Zegan wrote:
> W dniu 2012-07-17 15:57, Ron Wheeler pisze:
> >>> If you exclude the stock version from the direct dependencies and
add your version as a
> dependency, you:
> >>> a) get the configuration that you want
> >>> b) you have documented in your POM, the exact configuration of
> software bits and pieces that are required to build what you want (your
> friends will someday love you for doing this or hate you if you don't)
> >>> Being sneaky sometimes looks efficient but seldom is in the long term.
> >>>
> >>> Ron
> >>> On 17/07/2012 9:49 AM, Michał Zegan wrote:
> 
> >>>
>>
>>
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJQBYDKAAoJEIm05B02l8E6sx8P/0KDjRu5k0dh7dB3z2IFsMOq
u3tHIPInudanW+yLtvRL98NQ8twJ+pfwpq4t6pxtwKoFCU0LYxqgK4n7JOtHF2c1
IVLQMQK2GGN+NlSQGRPIhf5vCc23q4aXOx5slQavDbkR/tAF/AdB/hecwhd3N4G0
Y3t/oYLEW8x9heSxf5Z3+nVJhu4/dfRD2GRTR0IwKLZ3sPORZ/GeZmxza9jEn1+M
0S8NVHxgKPv0KTlJuVpZ+VOsqzYUZw5b/6Cxm5vqbMgM5RrVCuSe05PdJdyt+U9r
iKDpzxrO/b3WmfU+VvgMD/W538hq2uy2AHO2//oSpA7aQpeq3LR03JfguYIRFCwG
VgoFihkZcs9WcaVqLxY65Wkd5FXJYvETgktornCqDdxMsm/hiMxi8PLn7zVrsmvI
bz66GpBTdByoUPotEv66d5jBONhmHIjVDnNKqhZcwDMd7M+pWFwdpz4oqM8aUwPS
oifn+NBee/fFNNKRVFSoKZjrSKEBWcS72+4JTVdKs7w+/s4Q8QHGg8baoz22odaq
7SexT4e/ItlA/fo8qr7mdsyeof6STnWPvP14SDXttYBP0U7PvMssee+ZQGljVKfi
tCliK80wNYxECRgwMuOhnaYXmjwtwyqpzn5hQQx/tplrddzt+2tv2phtNiOT/e+t
quAhpbvI0jrdBnqAwUlU
=/LKX
-END PGP SIGNATURE-

Re: Duplicate dependency with different scopes

[Graham Crosmarie]

A defines a dependency on D with scope test and is a pom project

B defines a dependency on D with compile (default) and is a jar project.
A is the parent pom of B.
When I run dependency:tree I get what I want for B : D with scope compile.

I have other projects (C) whose parent is A and which depend on B with scope 
compile(default).
My problem is that the D dependency for such projects is in scope test 
(inherited from A) instead of scope compile (retrieved through the dependency 
on B).

In other words Maven chooses the wrong scope for my C projects. In fact, I 
think it always takes the one from the before parent and ignores the one from 
the dependency.


On 17/07/2012 15:29, Aliaksei Lahachou wrote:

Hi!

In parent A, so you define scope in dependency or dependency management
section. If the latter, then it overrides scope of the transitive
dependency.

In which scope is dependency B? If it's in test scope, than its
dependencies will be in test scope, too.

It would be much easier if you could show the POMs.

Regards,
htfv (Aliaksei Lahachou)
Am 17.07.2012 09:15 schrieb "Graham Crosmarie" <
graham.crosma...@linagora.com>:


Hello,

I have a problem with my dependency pattern and I am not sure that maven
behaves correctly in this case.

Here is my case :
 - I am using Maven 2.2.1.
 - I have a project A which defines a dependency D with scope test.
 - I have a project B whose parent is A and which defines D as a
dependency in scope compile.
 - My project hierarchy defines a lot of projects whose parent is A and
who have B as a dependency.

My problem is : all these "subprojects" have D as dependency in scope test
(from A).
I think that the correct behaviour would be to have D with scope compile
(from their dependency on B) because scope compile 'contains' scope test.
But Maven 2.2.1 does not work that way :-).

Is there any way to force my projects to use the D scope from project B
instead of the one from its parent (project A) ?

Thanks in avance,

--
Signature
Graham CROSMARIE
R&D Engineer
Linagora GSO -- www.linagora.com 




--
Signature
Graham CROSMARIE
R&D Engineer
Linagora GSO -- www.linagora.com 

Re: problems with deploying to a remote repository

[krishna chaitanya kurnala]

Hi there,

Try with mvn deploy:deployfile,
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

Thanks,
Krishna Kurnala


On Tue, Jul 17, 2012 at 4:28 AM, Michał Zegan wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello.
> How do you use mvn command line to deploy an artifact to a remote
> repository? it says it doesn't have a proper vagon provider for sftp/scp
> so... and it doesn't autodownload it.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJQBUxWAAoJEIm05B02l8E69t0P/jowMiX4G+mxBakLGVAv6wtM
> utDKJGLd3IGf7po105+i7bsv+8VUtO7rvqOMaqyb9M10SYxW1e4aYFLkeK/vTB9i
> JgezVJPcxbGGmrWe5v5VpTeUZnzNV9dQpCIRS6G9ncnbEoJ6obSsqEd7+6iFf75R
> RtKXXxja2RqaSorUtjhA89bonvnE06P43kuqROyJVElEDdpsLWgEqFWSpb10vEBN
> xOHAfkrT3lvZeO4r6OPRIj5D3KHBuGA5/IRaFLj5Ar+XqR0uguIq431r63RzXOge
> 7ByzgVTRdbRIPaYWTJCiYmdYcHGoAvWy1dKLCrNDfTrBc4gRjj/EJW9BL47LWlG7
> y/viV7WAIM4B6w5nBsygHeZCGvoJUB19RRwrj3ZRAXJE9aZP6/QDtQZ+vi/Is5c1
> MPTSbyljS5+xufdVyODfgRRm+AYoh3I5ndk/cg1Kr3wUqz+aZlRgQSfX0zyzx5i/
> BI4SEmicXyCy47A7juD5BsSybuqQCT7VeoU669daj4RVklk5vEL7PuJsbNA9yuuT
> e+EIVzhHd6kyFkQEl74yeX6gVLLaPDjIwUqNR4M8XiXsr7iTgd15/wFxtxNsM39f
> yuZgIo6a/A3amnu8VvKnbNa3BK1JT8bJnl2KfWKuZ+QuU+mANAo7q8By8vQtaITz
> H22jJPungGtZfGlokAJN
> =jcXr
> -END PGP SIGNATURE-
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: best practices

[Ron Wheeler]

Sometimes a best practice requires you to do things that you don't want 
to do for short term reasons.


Why not add an exclusion for stuff you want Maven to exclude?

Ron

On 17/07/2012 10:02 AM, Michał Zegan wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
  
I don't want to add exclusions for everything that requires that.


W dniu 2012-07-17 15:57, Ron Wheeler pisze:

If you exclude the stock version from the direct dependencies and add your 
version as a

dependency, you:

a) get the configuration that you want
b) you have documented in your POM, the exact configuration of

software bits and pieces that are required to build what you want (your
friends will someday love you for doing this or hate you if you don't)

Being sneaky sometimes looks efficient but seldom is in the long term.

Ron
On 17/07/2012 9:49 AM, Michał Zegan wrote:





-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
  
iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+

hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM
yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6
HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5
AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv
pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ
g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu
IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd
2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN
ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY
hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h
rwN/9SRuRuwqpRiGSI31
=znFZ
-END PGP SIGNATURE-





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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

Re: best practices

[Stephen Connolly]

What happens if any dependencies are looking for that support?

Will they bomb out or fail gracefully?

I.O.W. if you can still drop it in as a generic replacement => version
change

If you cannot use it as a generic replacement => different artifact =>
change groupId

for example...

I have https://github.com/stephenc/redmine-java-api which is
https://github.com/taskadapter/redmine-java-api switched to use slf4j in
place of some crappy piece of sh1t logging adapter code they rolled
themselves. Because I have altered the API contract by removing their
logging adapter code I maintain that at a different groupId. It is
otherwise API compatible, but the changes I have made are breaking changes
so I moved the groupId (never mind I needed a working version in central so
I had to change the groupId anyway... I *could* have got away with pushing
an alternative version number to our corp maven repo)

On 17 July 2012 15:09, Michał Zegan  wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> For example recompiling to drop compatibility with unsupported jsr14
> (namely osgi 4.3).
>
> W dniu 2012-07-17 16:05, Stephen Connolly pisze:
> > What none of us know is the scope of changes between this artifact and
> the
> > original...
> >
> > if all you are doing is rolling a cut from the latest SCM head because
> you
> > cannot wait for the next release => just change the version
> >
> > if you are majorly refactoring in such a way that the API or behaviour
> > contract will be changed => change the groupId
> >
> > if you are somewhere in between, you are going to have to make that call
> >
> > -Stephen
> >
> > On 17 July 2012 15:02, Michał Zegan  wrote:
> >
> >>
> > I don't want to add exclusions for everything that requires that.
> >
> > W dniu 2012-07-17 15:57, Ron Wheeler pisze:
> > >>> If you exclude the stock version from the direct dependencies and add
> > your version as a
> > dependency, you:
> > >>> a) get the configuration that you want
> > >>> b) you have documented in your POM, the exact configuration of
> > software bits and pieces that are required to build what you want (your
> > friends will someday love you for doing this or hate you if you don't)
> > >>>
> > >>> Being sneaky sometimes looks efficient but seldom is in the long
> term.
> > >>>
> > >>> Ron
> > >>> On 17/07/2012 9:49 AM, Michał Zegan wrote:
> > 
> > 
> > >>>
> > >>>
> >
> >>
> >>
> >
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJQBXH8AAoJEIm05B02l8E6CKsP/RBlMDopk2hlWwkZGd3WkWyU
> zNiBSW0HPaAVffsr6aniscYBhPviqywOd/IklRhuqBtPtszrCGyO1SXem4zuW1jq
> FZTTG5Zj+NzsIIG/FVYZKhudIc99eBRrgkuy5VM+cutpuq1+NyWdEZLDtYGR+bGy
> YlO9qGB59sWTxXbk2Om5C2z5+1QreNT8soCMHPbULg+SxyLI8yNCD1N6+bx7zvhU
> JRsrA51fA76kQx2ch31I/pIxTdK3c9f9mttB7Wuf1zGXkmhv9NTDljZ03DzlD4IW
> XxahO6E5KC79NN16q+fvUwFPcjw2HR3FmyYQGiOc5XmqUC/fUBySFTj9G9mKwQGn
> BRl8K2jO0C3X44hscEJjhXS204nGlwGpH0IUQTLGyF2f+dz+7meE4i6GqlvwEjaT
> ZENnLzX0eS0dbQYem3FJeUXIoUjjUp70myq4rq7bvKHerrRQFHlGL7f+ApLStJX5
> Ps0qTH/xGtsU+PjPTNd3RJKyWfk4WvbXNVWjT+kLrlqL6pXommgI5/MZrAozot8m
> jR3Slbhy/J1KI7xcu4yL6aEyWVDU7qwZHXVvyVj6SjFAMvlMX3YwtcpilG2P1Ljh
> en/MKDTdUF8GKO4M/iOk59QJ7IPlD1FJq88UEiL/M6k0CuZzY/nRIZ6MnXTDBVoa
> +KHubq8FPLWhrg3Ma3Al
> =eu/j
> -END PGP SIGNATURE-
>
>

Re: best practices

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
For example recompiling to drop compatibility with unsupported jsr14
(namely osgi 4.3).

W dniu 2012-07-17 16:05, Stephen Connolly pisze:
> What none of us know is the scope of changes between this artifact and the
> original...
>
> if all you are doing is rolling a cut from the latest SCM head because you
> cannot wait for the next release => just change the version
>
> if you are majorly refactoring in such a way that the API or behaviour
> contract will be changed => change the groupId
>
> if you are somewhere in between, you are going to have to make that call
>
> -Stephen
>
> On 17 July 2012 15:02, Michał Zegan  wrote:
>
>>
> I don't want to add exclusions for everything that requires that.
>
> W dniu 2012-07-17 15:57, Ron Wheeler pisze:
> >>> If you exclude the stock version from the direct dependencies and add
> your version as a
> dependency, you:
> >>> a) get the configuration that you want
> >>> b) you have documented in your POM, the exact configuration of
> software bits and pieces that are required to build what you want (your
> friends will someday love you for doing this or hate you if you don't)
> >>>
> >>> Being sneaky sometimes looks efficient but seldom is in the long term.
> >>>
> >>> Ron
> >>> On 17/07/2012 9:49 AM, Michał Zegan wrote:
> 
> 
> >>>
> >>>
>
>>
>>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJQBXH8AAoJEIm05B02l8E6CKsP/RBlMDopk2hlWwkZGd3WkWyU
zNiBSW0HPaAVffsr6aniscYBhPviqywOd/IklRhuqBtPtszrCGyO1SXem4zuW1jq
FZTTG5Zj+NzsIIG/FVYZKhudIc99eBRrgkuy5VM+cutpuq1+NyWdEZLDtYGR+bGy
YlO9qGB59sWTxXbk2Om5C2z5+1QreNT8soCMHPbULg+SxyLI8yNCD1N6+bx7zvhU
JRsrA51fA76kQx2ch31I/pIxTdK3c9f9mttB7Wuf1zGXkmhv9NTDljZ03DzlD4IW
XxahO6E5KC79NN16q+fvUwFPcjw2HR3FmyYQGiOc5XmqUC/fUBySFTj9G9mKwQGn
BRl8K2jO0C3X44hscEJjhXS204nGlwGpH0IUQTLGyF2f+dz+7meE4i6GqlvwEjaT
ZENnLzX0eS0dbQYem3FJeUXIoUjjUp70myq4rq7bvKHerrRQFHlGL7f+ApLStJX5
Ps0qTH/xGtsU+PjPTNd3RJKyWfk4WvbXNVWjT+kLrlqL6pXommgI5/MZrAozot8m
jR3Slbhy/J1KI7xcu4yL6aEyWVDU7qwZHXVvyVj6SjFAMvlMX3YwtcpilG2P1Ljh
en/MKDTdUF8GKO4M/iOk59QJ7IPlD1FJq88UEiL/M6k0CuZzY/nRIZ6MnXTDBVoa
+KHubq8FPLWhrg3Ma3Al
=eu/j
-END PGP SIGNATURE-

Re: best practices

[Stephen Connolly]

What none of us know is the scope of changes between this artifact and the
original...

if all you are doing is rolling a cut from the latest SCM head because you
cannot wait for the next release => just change the version

if you are majorly refactoring in such a way that the API or behaviour
contract will be changed => change the groupId

if you are somewhere in between, you are going to have to make that call

-Stephen

On 17 July 2012 15:02, Michał Zegan  wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I don't want to add exclusions for everything that requires that.
>
> W dniu 2012-07-17 15:57, Ron Wheeler pisze:
> > If you exclude the stock version from the direct dependencies and add
> your version as a
> dependency, you:
> > a) get the configuration that you want
> > b) you have documented in your POM, the exact configuration of
> software bits and pieces that are required to build what you want (your
> friends will someday love you for doing this or hate you if you don't)
> >
> > Being sneaky sometimes looks efficient but seldom is in the long term.
> >
> > Ron
> > On 17/07/2012 9:49 AM, Michał Zegan wrote:
> >>
> >>
> >
> >
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+
> hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM
> yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6
> HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5
> AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv
> pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ
> g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu
> IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd
> 2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN
> ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY
> hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h
> rwN/9SRuRuwqpRiGSI31
> =znFZ
> -END PGP SIGNATURE-
>
>

Re: best practices

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
I don't want to add exclusions for everything that requires that.

W dniu 2012-07-17 15:57, Ron Wheeler pisze:
> If you exclude the stock version from the direct dependencies and add your 
> version as a
dependency, you:
> a) get the configuration that you want
> b) you have documented in your POM, the exact configuration of
software bits and pieces that are required to build what you want (your
friends will someday love you for doing this or hate you if you don't)
>
> Being sneaky sometimes looks efficient but seldom is in the long term.
>
> Ron
> On 17/07/2012 9:49 AM, Michał Zegan wrote:
>>
>>
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+
hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM
yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6
HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5
AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv
pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ
g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu
IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd
2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN
ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY
hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h
rwN/9SRuRuwqpRiGSI31
=znFZ
-END PGP SIGNATURE-

Re: best practices

[Ron Wheeler]

If you exclude the stock version from the direct dependencies and add 
your version as a dependency, you:

a) get the configuration that you want
b) you have documented in your POM, the exact configuration of software 
bits and pieces that are required to build what you want (your friends 
will someday love you for doing this or hate you if you don't)


Being sneaky sometimes looks efficient but seldom is in the long term.

Ron
On 17/07/2012 9:49 AM, Michał Zegan wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
  
But it would not work for transitive ependencies if I'll put it in a

different group id, I think. because they are different projects.
W dniu 2012-07-17 15:39, Anders Hammar pisze:

I think it would depend on what kind of changes you make. But if it's
a patch or similar, you should just change the version to
a.b.c-PATCH123 or something (keep artifactId and groupId as the
original).

But if you make bigger changes to it, it would probably make sense to
put it under your groupId.

/Anders

On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan
 wrote:
Hello.

What is the best way to do things like:
Some artifact exists in a central repository and it's a transitive
dependency of some of my project's direct dependencies.
Then, I have a really good reason to modify the artifact and store it in
my own repository.
Should I distinguish the new version of it using a classifier, a version
like 0.0-modified, or I should make the coordinates the same as in

central?


-
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



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
  
iQIcBAEBAgAGBQJQBW12AAoJEIm05B02l8E6x4oP/27oOsR5oOw5qYqYc/HSjs6z

awbD/mw9MFocKF3XnzWbkF/AnxAK+kxxyJAtFjQ6dY9e6xEMrZKVGJ61ahuzz7hn
H//PlXavX9tyRE0eqmmauanNFZaohr6SoXOgHAvTeCh5HAizHf8nAT0FT4HJTb9J
LCMbpcE1ZFdSJ+rQMFS+IGPtYBYNQKylEaG1C9eP7os2hxIrwuxe0SVOPdrhmzrB
KbFaORYbVa5660AcX/i7F6DZae8Bnp1AShLYa/2ecyDx6352z/olKju9iFbwkoEb
3WtFrzhIdDtKEPh7NzU2wCYPwXwhhkgTgGjDkLkC6/WjRTfZQoQJzMo/nGQn0uGB
GY7uuGT82VpqI6IhubhKzJh4ddFmucu2AtCnxpuwhQ3q09h8UaHCCVmA3QLcnBVg
moLbHGk/4bnub+sspoSH4gHPdhNiLWJbWXoj2SpR8v6IyeSenGxwndjrrf1j/bHX
bplkMmAINlyaPhOBmt41iy1kzLhz4BNbBSaFCUbS71yyNh0AUBRNC1HDgzA8VSe+
J4lBv/UFcI+gWZjyN3ih+S35oIVymjSUwjeU32XJq7zWkdLGi5x9AqhsEsTYzKyf
zGLhIxdKMDIirTvX4nS2dlv7F8fx+8X06Vg1JgR1F0zZRnuGk+Sw1sPyy67aSlhj
kjk+CPQAjzMTS5xKkdig
=/tS3
-END PGP SIGNATURE-





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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

Re: best practices

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
But it would not work for transitive ependencies if I'll put it in a
different group id, I think. because they are different projects.
W dniu 2012-07-17 15:39, Anders Hammar pisze:
> I think it would depend on what kind of changes you make. But if it's
> a patch or similar, you should just change the version to
> a.b.c-PATCH123 or something (keep artifactId and groupId as the
> original).
>
> But if you make bigger changes to it, it would probably make sense to
> put it under your groupId.
>
> /Anders
>
> On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan
>  wrote:
>>
> Hello.
>
> What is the best way to do things like:
> Some artifact exists in a central repository and it's a transitive
> dependency of some of my project's direct dependencies.
> Then, I have a really good reason to modify the artifact and store it in
> my own repository.
> Should I distinguish the new version of it using a classifier, a version
> like 0.0-modified, or I should make the coordinates the same as in
central?
>>
>>
>> -
>> 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
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJQBW12AAoJEIm05B02l8E6x4oP/27oOsR5oOw5qYqYc/HSjs6z
awbD/mw9MFocKF3XnzWbkF/AnxAK+kxxyJAtFjQ6dY9e6xEMrZKVGJ61ahuzz7hn
H//PlXavX9tyRE0eqmmauanNFZaohr6SoXOgHAvTeCh5HAizHf8nAT0FT4HJTb9J
LCMbpcE1ZFdSJ+rQMFS+IGPtYBYNQKylEaG1C9eP7os2hxIrwuxe0SVOPdrhmzrB
KbFaORYbVa5660AcX/i7F6DZae8Bnp1AShLYa/2ecyDx6352z/olKju9iFbwkoEb
3WtFrzhIdDtKEPh7NzU2wCYPwXwhhkgTgGjDkLkC6/WjRTfZQoQJzMo/nGQn0uGB
GY7uuGT82VpqI6IhubhKzJh4ddFmucu2AtCnxpuwhQ3q09h8UaHCCVmA3QLcnBVg
moLbHGk/4bnub+sspoSH4gHPdhNiLWJbWXoj2SpR8v6IyeSenGxwndjrrf1j/bHX
bplkMmAINlyaPhOBmt41iy1kzLhz4BNbBSaFCUbS71yyNh0AUBRNC1HDgzA8VSe+
J4lBv/UFcI+gWZjyN3ih+S35oIVymjSUwjeU32XJq7zWkdLGi5x9AqhsEsTYzKyf
zGLhIxdKMDIirTvX4nS2dlv7F8fx+8X06Vg1JgR1F0zZRnuGk+Sw1sPyy67aSlhj
kjk+CPQAjzMTS5xKkdig
=/tS3
-END PGP SIGNATURE-

Re: best practices

[Anders Hammar]

I think it would depend on what kind of changes you make. But if it's
a patch or similar, you should just change the version to
a.b.c-PATCH123 or something (keep artifactId and groupId as the
original).

But if you make bigger changes to it, it would probably make sense to
put it under your groupId.

/Anders

On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello.
>
> What is the best way to do things like:
> Some artifact exists in a central repository and it's a transitive
> dependency of some of my project's direct dependencies.
> Then, I have a really good reason to modify the artifact and store it in
> my own repository.
> Should I distinguish the new version of it using a classifier, a version
> like 0.0-modified, or I should make the coordinates the same as in central?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJQBWiTAAoJEIm05B02l8E6S6YP/i2OTRi04zHS/8yEBMabeI6g
> e0BVVir6EI/l8+0NvuOVj0WI6gBxFDvajr6NHaQC/Eg1C6NHyTdCXrMXjeHLxcst
> Z8Fqe+dOSF3zkvjUFpgU4NgvSxiuUKPc/2hcezYBMF/Q8IIDUJpR2sZpHmp0JdH+
> iZIpcxPp1wzqwtWUvherMtjI351vyBSVWaPfoRPNFTeOXxCyR4WQmXeGQkMnG+9S
> MpMAAACfdT6Hsjhvnq4CzrzItBpfIrgXWcXtM6mmyN92t2CumYTvpwWlF2iHNWyS
> VvoIOoSntm6TBtk8vPtrMvC0vDTVJ6Cd3YdWAFacByy9kh+cjeATTUMKc/W+lbMn
> FfTK4FAxQNqRUUa93MBBZydw0dKeLg4w+YulI4u6p219HtBNjtq1UuMAyXrEn/xk
> xRysKjqpM2d2kkUiPvCJde/p6AarLpUK1GfVvzF9a/tff6nkOlt9AgaBmiJ/OiTt
> o0yXIjo3ovJcBoGoPUC60qswDH5goKYJH1vkVaAj2ey8cFuwGNPrqGbjEiGgDtij
> xU9KSzUOoOLxB6feskXEivgL+gxDK8+okJ4vLgglLezRaFMX5CXF+yttybXVyuK+
> kE/mnl4Yx8gIIcogZLb1+kHsFqp1VHQvyfrzOadplOLTchbQUDfWpaS2EwztODQk
> JtJsjfipQYirRjF5RfnD
> =WGSq
> -END PGP SIGNATURE-
>
>
> -
> 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: Duplicate dependency with different scopes

[Aliaksei Lahachou]

Hi!

In parent A, so you define scope in dependency or dependency management
section. If the latter, then it overrides scope of the transitive
dependency.

In which scope is dependency B? If it's in test scope, than its
dependencies will be in test scope, too.

It would be much easier if you could show the POMs.

Regards,
htfv (Aliaksei Lahachou)
Am 17.07.2012 09:15 schrieb "Graham Crosmarie" <
graham.crosma...@linagora.com>:

> Hello,
>
> I have a problem with my dependency pattern and I am not sure that maven
> behaves correctly in this case.
>
> Here is my case :
> - I am using Maven 2.2.1.
> - I have a project A which defines a dependency D with scope test.
> - I have a project B whose parent is A and which defines D as a
> dependency in scope compile.
> - My project hierarchy defines a lot of projects whose parent is A and
> who have B as a dependency.
>
> My problem is : all these "subprojects" have D as dependency in scope test
> (from A).
> I think that the correct behaviour would be to have D with scope compile
> (from their dependency on B) because scope compile 'contains' scope test.
> But Maven 2.2.1 does not work that way :-).
>
> Is there any way to force my projects to use the D scope from project B
> instead of the one from its parent (project A) ?
>
> Thanks in avance,
>
> --
> Signature
> Graham CROSMARIE
> R&D Engineer
> Linagora GSO -- www.linagora.com 
>

best practices

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hello.

What is the best way to do things like:
Some artifact exists in a central repository and it's a transitive
dependency of some of my project's direct dependencies.
Then, I have a really good reason to modify the artifact and store it in
my own repository.
Should I distinguish the new version of it using a classifier, a version
like 0.0-modified, or I should make the coordinates the same as in central?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJQBWiTAAoJEIm05B02l8E6S6YP/i2OTRi04zHS/8yEBMabeI6g
e0BVVir6EI/l8+0NvuOVj0WI6gBxFDvajr6NHaQC/Eg1C6NHyTdCXrMXjeHLxcst
Z8Fqe+dOSF3zkvjUFpgU4NgvSxiuUKPc/2hcezYBMF/Q8IIDUJpR2sZpHmp0JdH+
iZIpcxPp1wzqwtWUvherMtjI351vyBSVWaPfoRPNFTeOXxCyR4WQmXeGQkMnG+9S
MpMAAACfdT6Hsjhvnq4CzrzItBpfIrgXWcXtM6mmyN92t2CumYTvpwWlF2iHNWyS
VvoIOoSntm6TBtk8vPtrMvC0vDTVJ6Cd3YdWAFacByy9kh+cjeATTUMKc/W+lbMn
FfTK4FAxQNqRUUa93MBBZydw0dKeLg4w+YulI4u6p219HtBNjtq1UuMAyXrEn/xk
xRysKjqpM2d2kkUiPvCJde/p6AarLpUK1GfVvzF9a/tff6nkOlt9AgaBmiJ/OiTt
o0yXIjo3ovJcBoGoPUC60qswDH5goKYJH1vkVaAj2ey8cFuwGNPrqGbjEiGgDtij
xU9KSzUOoOLxB6feskXEivgL+gxDK8+okJ4vLgglLezRaFMX5CXF+yttybXVyuK+
kE/mnl4Yx8gIIcogZLb1+kHsFqp1VHQvyfrzOadplOLTchbQUDfWpaS2EwztODQk
JtJsjfipQYirRjF5RfnD
=WGSq
-END PGP SIGNATURE-


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

Re: Dependencies between the "test" sections of modules?

[org.apache.maven.user]

On Tue, 17 Jul 2012 14:44:57 +0200
Anders Hammar  wrote:

> Yes, create a jar of the test classes:
> http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html
> 
> There are some limitations in this though (test dependencies are not
> transitive). Moving these test classes to a separate project solves
> that.

On Tue, 17 Jul 2012 14:45:37 +0200
Thomas Broyer  wrote:

> Sure, add a dependency on the "test-jar" (and of course generate and
> attach it in P.Core).
> See http://maven.apache.org/guides/mini/guide-attached-tests.html

Thanks, all.

I'll try it.

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

Re: Dependencies between the "test" sections of modules?

[Thomas Broyer]

On Tue, Jul 17, 2012 at 2:39 PM,   wrote:
> I have a multi-module project P, with modules P.Core, P.A, P.B.
>
> Both P.A and P.B are different implementations of an API specified
> in P.Core. In order to test that all implementations of P.Core have
> the same semantics, P.Core exports a set of abstract classes containing
> junit 4 tests which are then completed by P.A and P.B.
>
> The problem is this: classes defined in p-core/src/main/test are not
> visible from p-a/src/main/test or p-b/src/main/test. Moving the classes
> into p-core/src/main/java makes them visible to the tests defined in
> the other modules, but then this means that the junit dependency has
> to be moved from the test phase of P.Core to the compile phase, which
> is somewhat irritating.
>
> Is there a way allow the 'test' sections of modules to see each other?

Sure, add a dependency on the "test-jar" (and of course generate and
attach it in P.Core).
See http://maven.apache.org/guides/mini/guide-attached-tests.html


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

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

Re: Dependencies between the "test" sections of modules?

[Anders Hammar]

Yes, create a jar of the test classes:
http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html

There are some limitations in this though (test dependencies are not
transitive). Moving these test classes to a separate project solves
that.

/Anders

On Tue, Jul 17, 2012 at 2:39 PM,   wrote:
> I have a multi-module project P, with modules P.Core, P.A, P.B.
>
> Both P.A and P.B are different implementations of an API specified
> in P.Core. In order to test that all implementations of P.Core have
> the same semantics, P.Core exports a set of abstract classes containing
> junit 4 tests which are then completed by P.A and P.B.
>
> The problem is this: classes defined in p-core/src/main/test are not
> visible from p-a/src/main/test or p-b/src/main/test. Moving the classes
> into p-core/src/main/java makes them visible to the tests defined in
> the other modules, but then this means that the junit dependency has
> to be moved from the test phase of P.Core to the compile phase, which
> is somewhat irritating.
>
> Is there a way allow the 'test' sections of modules to see each other?
>
> -
> 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

transitive provided dependencies: a little question

[Marco Speranza]

Hi all...

a friend of mine and I have experienced a compilation error when we
have tried to compile this project:

prj.a:
public class A extends B{}

prj.b:
public class B extends C{}

prj.c:
public class C{}

where their pom are:

prj.a -> prj.b (provided scope)

prj.b -> prj.c (provided scope)

our compilation fails because C is not included in A's compile
classpath as shown in the table [1]

My question is... why the transitive 'provided' dependencies of a
'provided' dependency are not transitive and the transitive
*'runtime'* dependencies of a 'provided' dependency is transitive?

IMHO would be better that provided dependencies are transitive and
runtime dependencies not, it isn't?


have a nice day... :-)


[1]: 
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope


--
Marco Speranza 
Google Code: http://code.google.com/u/marco.speranza79/

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

Dependencies between the "test" sections of modules?

[org.apache.maven.user]

I have a multi-module project P, with modules P.Core, P.A, P.B.

Both P.A and P.B are different implementations of an API specified
in P.Core. In order to test that all implementations of P.Core have
the same semantics, P.Core exports a set of abstract classes containing
junit 4 tests which are then completed by P.A and P.B.

The problem is this: classes defined in p-core/src/main/test are not
visible from p-a/src/main/test or p-b/src/main/test. Moving the classes
into p-core/src/main/java makes them visible to the tests defined in
the other modules, but then this means that the junit dependency has
to be moved from the test phase of P.Core to the compile phase, which
is somewhat irritating.

Is there a way allow the 'test' sections of modules to see each other?

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

problems with deploying to a remote repository

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hello.
How do you use mvn command line to deploy an artifact to a remote
repository? it says it doesn't have a proper vagon provider for sftp/scp
so... and it doesn't autodownload it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJQBUxWAAoJEIm05B02l8E69t0P/jowMiX4G+mxBakLGVAv6wtM
utDKJGLd3IGf7po105+i7bsv+8VUtO7rvqOMaqyb9M10SYxW1e4aYFLkeK/vTB9i
JgezVJPcxbGGmrWe5v5VpTeUZnzNV9dQpCIRS6G9ncnbEoJ6obSsqEd7+6iFf75R
RtKXXxja2RqaSorUtjhA89bonvnE06P43kuqROyJVElEDdpsLWgEqFWSpb10vEBN
xOHAfkrT3lvZeO4r6OPRIj5D3KHBuGA5/IRaFLj5Ar+XqR0uguIq431r63RzXOge
7ByzgVTRdbRIPaYWTJCiYmdYcHGoAvWy1dKLCrNDfTrBc4gRjj/EJW9BL47LWlG7
y/viV7WAIM4B6w5nBsygHeZCGvoJUB19RRwrj3ZRAXJE9aZP6/QDtQZ+vi/Is5c1
MPTSbyljS5+xufdVyODfgRRm+AYoh3I5ndk/cg1Kr3wUqz+aZlRgQSfX0zyzx5i/
BI4SEmicXyCy47A7juD5BsSybuqQCT7VeoU669daj4RVklk5vEL7PuJsbNA9yuuT
e+EIVzhHd6kyFkQEl74yeX6gVLLaPDjIwUqNR4M8XiXsr7iTgd15/wFxtxNsM39f
yuZgIo6a/A3amnu8VvKnbNa3BK1JT8bJnl2KfWKuZ+QuU+mANAo7q8By8vQtaITz
H22jJPungGtZfGlokAJN
=jcXr
-END PGP SIGNATURE-


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

Re: Duplicate dependency with different scopes

[Anders Hammar]

Well, I disagree with you. A pom project doesn't have a dependency. It
doesn't have any code and thus no dependencies.

Also, based on my experience, there will always be exceptions to the
rule "all children will have this dependency". A very common one is
thinking that all children will have a junit test dependency. Sounds
reasonable in the beginning, but what happens when you have an API
module? This one is very unlikely to have any tests as it only
includes interfaces (or possibly very simple classes). And then it
will get an incorrect dependency. Sure, an extra test scope dependency
will not affect any project having a dependency, but this is still an
incorrect dependency.

/Anders

On Tue, Jul 17, 2012 at 10:57 AM, Graham Crosmarie
 wrote:
> Thanks for your answer,
>
> But somehow I disagree with you : a pom project might have to define
> dependencies.
> IMHO defining such a dependency (besides defining its version and scope in
> the dependency management) is legitimate if all of the projects having this
> pom as parent should have this dependency.
>
> For example our parent pom which is the parent of all our other projects
> defines Junit as a dependency because we know all of our prejects are going
> to use Junit.
>
> In my case all subprojects of A need D at least in scope test but some of
> them (which depends on B) appears to 'also' need D in scope compile.
>
>
> On 17/07/2012 09:43, Anders Hammar wrote:
>>
>> As project A is a parent it's a pom project, right? IMHO a pom project
>> should NEVER have a dependency. Remove that dependency and state that
>> test scope dependency where it actually is a dependency instead.
>> Project A could however have dependencyManagement declared for D
>> stating test as default scope (and version).
>>
>> /Anders
>>
>> On Tue, Jul 17, 2012 at 9:15 AM, Graham Crosmarie
>>  wrote:
>>>
>>> Hello,
>>>
>>> I have a problem with my dependency pattern and I am not sure that maven
>>> behaves correctly in this case.
>>>
>>> Here is my case :
>>>  - I am using Maven 2.2.1.
>>>  - I have a project A which defines a dependency D with scope test.
>>>  - I have a project B whose parent is A and which defines D as a
>>> dependency in scope compile.
>>>  - My project hierarchy defines a lot of projects whose parent is A
>>> and
>>> who have B as a dependency.
>>>
>>> My problem is : all these "subprojects" have D as dependency in scope
>>> test
>>> (from A).
>>> I think that the correct behaviour would be to have D with scope compile
>>> (from their dependency on B) because scope compile 'contains' scope test.
>>> But Maven 2.2.1 does not work that way :-).
>>>
>>> Is there any way to force my projects to use the D scope from project B
>>> instead of the one from its parent (project A) ?
>>>
>>> Thanks in avance,
>>>
>>> --
>>> Signature
>>> Graham CROSMARIE
>>> R&D Engineer
>>> Linagora GSO -- www.linagora.com 
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
>
> --
> Signature
> Graham CROSMARIE
> R&D Engineer
> Linagora GSO -- www.linagora.com 

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

Re: Duplicate dependency with different scopes

[Jörg Schaible]

Hi Graham,

Graham Crosmarie wrote:

> Thanks for your answer,
> 
> But somehow I disagree with you : a pom project might have to define
> dependencies.
> IMHO defining such a dependency (besides defining its version and scope
> in the dependency management) is legitimate if all of the projects
> having this pom as parent should have this dependency.
> 
> For example our parent pom which is the parent of all our other projects
> defines Junit as a dependency because we know all of our prejects are
> going to use Junit.
> 
> In my case all subprojects of A need D at least in scope test but some
> of them (which depends on B) appears to 'also' need D in scope compile.

well, Maven gives you, what you have defined. If you define D for all 
projects directly as scope test, why do you complain at all?

- Jörg


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

Re: Duplicate dependency with different scopes

[Graham Crosmarie]

Thanks for your answer,

But somehow I disagree with you : a pom project might have to define 
dependencies.
IMHO defining such a dependency (besides defining its version and scope 
in the dependency management) is legitimate if all of the projects 
having this pom as parent should have this dependency.


For example our parent pom which is the parent of all our other projects 
defines Junit as a dependency because we know all of our prejects are 
going to use Junit.


In my case all subprojects of A need D at least in scope test but some 
of them (which depends on B) appears to 'also' need D in scope compile.



On 17/07/2012 09:43, Anders Hammar wrote:

As project A is a parent it's a pom project, right? IMHO a pom project
should NEVER have a dependency. Remove that dependency and state that
test scope dependency where it actually is a dependency instead.
Project A could however have dependencyManagement declared for D
stating test as default scope (and version).

/Anders

On Tue, Jul 17, 2012 at 9:15 AM, Graham Crosmarie
 wrote:

Hello,

I have a problem with my dependency pattern and I am not sure that maven
behaves correctly in this case.

Here is my case :
 - I am using Maven 2.2.1.
 - I have a project A which defines a dependency D with scope test.
 - I have a project B whose parent is A and which defines D as a
dependency in scope compile.
 - My project hierarchy defines a lot of projects whose parent is A and
who have B as a dependency.

My problem is : all these "subprojects" have D as dependency in scope test
(from A).
I think that the correct behaviour would be to have D with scope compile
(from their dependency on B) because scope compile 'contains' scope test.
But Maven 2.2.1 does not work that way :-).

Is there any way to force my projects to use the D scope from project B
instead of the one from its parent (project A) ?

Thanks in avance,

--
Signature
Graham CROSMARIE
R&D Engineer
Linagora GSO -- www.linagora.com 

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




--
Signature
Graham CROSMARIE
R&D Engineer
Linagora GSO -- www.linagora.com 

Re: Duplicate dependency with different scopes

[Anders Hammar]

As project A is a parent it's a pom project, right? IMHO a pom project
should NEVER have a dependency. Remove that dependency and state that
test scope dependency where it actually is a dependency instead.
Project A could however have dependencyManagement declared for D
stating test as default scope (and version).

/Anders

On Tue, Jul 17, 2012 at 9:15 AM, Graham Crosmarie
 wrote:
> Hello,
>
> I have a problem with my dependency pattern and I am not sure that maven
> behaves correctly in this case.
>
> Here is my case :
> - I am using Maven 2.2.1.
> - I have a project A which defines a dependency D with scope test.
> - I have a project B whose parent is A and which defines D as a
> dependency in scope compile.
> - My project hierarchy defines a lot of projects whose parent is A and
> who have B as a dependency.
>
> My problem is : all these "subprojects" have D as dependency in scope test
> (from A).
> I think that the correct behaviour would be to have D with scope compile
> (from their dependency on B) because scope compile 'contains' scope test.
> But Maven 2.2.1 does not work that way :-).
>
> Is there any way to force my projects to use the D scope from project B
> instead of the one from its parent (project A) ?
>
> Thanks in avance,
>
> --
> Signature
> Graham CROSMARIE
> R&D Engineer
> Linagora GSO -- www.linagora.com 

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

Duplicate dependency with different scopes

[Graham Crosmarie]

Hello,

I have a problem with my dependency pattern and I am not sure that maven 
behaves correctly in this case.


Here is my case :
- I am using Maven 2.2.1.
- I have a project A which defines a dependency D with scope test.
- I have a project B whose parent is A and which defines D as a 
dependency in scope compile.
- My project hierarchy defines a lot of projects whose parent is A 
and who have B as a dependency.


My problem is : all these "subprojects" have D as dependency in scope 
test (from A).
I think that the correct behaviour would be to have D with scope compile 
(from their dependency on B) because scope compile 'contains' scope 
test. But Maven 2.2.1 does not work that way :-).


Is there any way to force my projects to use the D scope from project B 
instead of the one from its parent (project A) ?


Thanks in avance,

--
Signature
Graham CROSMARIE
R&D Engineer
Linagora GSO -- www.linagora.com