[ANN] TrueZIP Maven Plugin version 1.1 Released

[Dan Tran]

Hello

The Mojo team is pleased to announce the release of TrueZIP Maven Plugin 1.1

This plugin manipulates archive files of type zip, tar, tgz, tbz2,etc.
You can also use its truezip-utils component to perform the same
operations within your java application.

We solved 8 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12630&version=18614

  MTRUEZIP-27Add option to print out archive contents using relative path
  MTRUEZIP-22Align the mojo's namning in JIRA and in code
  MTRUEZIP-21Fix spelling errors etc in documentation
  MTRUEZIP-26Remove changes report, use JIRA report instead
  MTRUEZIP-20Remove maven dependency from truezip-core
  MTRUEZIP-25Remove stdout verbose mode
  MTRUEZIP-23Rename truezip-core module to truezip-utils
  MTRUEZIP-24upgrade to truezip 7.6

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


org.codehaus.mojo
truezip-maven-plugin
1.1


The project site is at  http://mojo.codehaus.org/truezip/truezip-maven-plugin


Additional information

- This release mainly to cleanup the shared component to minimize
dependency on Maven

- The verbose stdout is disable, and will be replaced by slf4j logger
if needed in the future


Thanks,

-Dan

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

Re: strategy for incorporating private jars into a project

[Manfred Moser]

I was going to suggest that as a stop gap solution, but realistically you
should be telling that other team that it is the year 2012 and they should
be using a repository manager. In the extreme case set it up for them and
get their release process going as well.

manfred

On Wed, September 19, 2012 8:09 am, Anthony Dahanne wrote:
> hello,
> why don't you push those private jars as snapshot versions into your
> local nexus ?
> Then in your build, use something like -U to make sure maven grabs the
> latest snapshots.
> Anthony
>
> On Wed, Sep 19, 2012 at 11:04 AM, mlandman99  wrote:
>> Hi,
>>
>> My java project has several dependencies, both external (i.e. in the
>> public
>> repo) and private (built by our own company). It's a QA project, that
>> can be
>> run locally in Eclipse, and also runs on a CI server (teamcity). When it
>> 'builds', it runs then maven phase: "integration-test", which then runs
>> testNG tests within my classes. So far so good.
>>
>> Unfortunately the private jars that it uses are not under any sort of
>> control. They are built by a different team in my company, and are
>> placed in
>> an available network-share, but that's it. They don't seem to be
>> properly
>> 'versioned', and are not placed in any local (nexus) repository, unless
>> I
>> manually put them there.
>>
>> For running nightly automated testing, I want to ensure I always utilize
>> the
>> most recent version of those private jars. So far, I've manually placed
>> a
>> version of them in a local nexus repo, and they are successfully pulled
>> down
>> when teamcity runs the build. But I don't have a way of getting the
>> nightly
>> builds up inside that nexus repo. Even if I did, they would always just
>> be
>> "version 1.0" and probably won't be re-downloaded anyway.
>>
>> So... I'm looking for suggestions re: a strategy on how to *ensure* that
>> each time my project is built, that it properly grabs the new version of
>> those private jars, of which the only reliable way to access them is in
>> a
>> network share drive. The other public jars are successfully managed by
>> maven.
>>
>> Is there a way to use Maven to help me pull in these private jars that
>> exist
>> on a network share? If anyone has any suggestions on a strategy re: how
>> I
>> can proceed, I'd appreciate it!
>>
>> Thanks!
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524.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 find more information about mvn "Unknown error trying to execute the external compiler

[Peter Kahn]

Hi all,

We found the cause of the problem - no memory for the fork.  We had java
processes in the background and set the compiler plugin to fork.  When
maven attempted fork it failed resulting in an error code but no error
information (at least none that the plugin could understand).

Should I log a bug on this?


FYI, I think there's an improvement we can make to the JavaCompiler code.
At present a failure with no message yields a generic error statement.
However, we do have a returnCode and could add this to the text providing a
few more bread crumbs to follow when we hit this kind of case.

if ( ( returnCode != 0 ) && messages.isEmpty() )
{
if ( err.getOutput().length() == 0 )
{
throw new CompilerException( "Unknown error trying to
execute the external compiler: " + EOL
+ cli.toString() );
}
else
{
messages.add( new CompilerError( "Failure executing javac,
but could not parse the error:" + EOL
+ err.getOutput(), true ) );
}
}


Thanks

Peter

On Wed, Sep 19, 2012 at 3:44 PM, Peter Kahn  wrote:

> Hi all,
>
> How can I investigate mvn *Unknown error trying to execute the external
> compiler*? According to compiler-plugin source in this case javac returns
> nonzero but mvn can't extract error information (alas mvn appears to eat
> the javac error code in this situation)- 
> JavacCompiler.Java.
> I know that Mvn has issues parsing java 7 output and I tried running java
> manually but I can't reproduce the error.
>
> I'm using mvn303, compiler plugin 2.5.1 and java 1.7 07.
>
>- mvn clean compile -X - *fails with error*
>- copy paste mvn's failed /bin/sh for javac invocation - *sh+javac
>completes without an error code*
>
> Let me know if you have any ideas on how to handle this situation.
>
> Thanks
>
> Peter
>
> `[ERROR] /bin/sh -c cd /myproj/modules/memory &&
> /usr/java/jdk1.7.0_07/jre/../bin/javac
> @/myproj/modules/memory/target/classes/org.codehaus.plexus.compiler.javac.JavacCompiler4013958444740287519arguments
> -J-Xmx512m -J-Xms512m [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
> (default-compile) on project memory: Fatal error compiling at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> ... ...
>
> org.codehaus.plexus.compiler.javac.JavacCompiler.compileOutOfProcess(JavacCompiler.java:488)
> at
> org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:157)`
>
>
> --
> Peter Kahn
> citizenk...@gmail.com
> http://www.google.com/profiles/citizenkahn
> Awareness - Intention - Action
>



-- 
Peter Kahn
citizenk...@gmail.com
http://www.google.com/profiles/citizenkahn
Awareness - Intention - Action

Re: strategy for incorporating private jars into a project

[Ron Wheeler]

What is the underlying problem for which a solution is sought?

Why are the jars so volatile?
Why is it so important to use the "latest" version and then track the 
history so carefully?

Describe the "release" cycle of the final product.

It sounds like this problem needs to be restated in higher level terms 
in order to get a reasonable solution.


Ron


On 19/09/2012 1:39 PM, Anthony Dahanne wrote:

you could do that...(not leveraging maven at all and writing custom
svn related scripts)
but you could also go the suggested "push snapshots to repo" way,
keeping a large snapshots history... (btw snapshots are tagged with a
timestamp)

On Wed, Sep 19, 2012 at 1:30 PM, mlandman99  wrote:

The suggestion (automatically upload to local repo) sounds like a good one,
though I thought of a different solution that I'd like your opinion on:

This project is used for running integration-level regression tests. The
project is checked into source control (SVN).

Conceivably, I may have a need to run the project tomorrow against an older
version of code. If I were to do this, I'd want to run with the same version
of the internal jars that I had used at that date.

If I were to tell SVN to load the project as of date/label x (might be a
release from 6 months ago..) -- and then run the project, I wouldn't want to
take the latest version of those internal jars, I'd want to use the version
that I used back at that date.

To that end, I was thinking of creating a subdirectory within the project
inside SVN reserved for holding those internal jars. This way, whenever I
revert the project back to SVN version , I'll be assured I'm using those
same version of those same internal jars that I had originally used on that
date/label.

To ensure I'm using the latest version (when I'm trying to run 'latest'), I
could write a script to auto-commit those jars to the subdirectory of my
project within SVN, overwriting the previous version. In reality it seems
very similar to the suggestion you had, but it's utilizing SVN to house
those artifacts instead of the local nexus repo.

What are your thoughts on this?

If I were to do this, what would the proper configuration be for Maven, i.e.
to treat this special subdirectory as a location for retrieving artifacts,
and to ensure that it's not cached, so that when I build, it will always use
the version in that directory?

Thanks for your help. I'm fairly new at this and appreciate the guidance.




--
View this message in context: 
http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5722573.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





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

How can I find more information about mvn "Unknown error trying to execute the external compiler

[Peter Kahn]

Hi all,

How can I investigate mvn *Unknown error trying to execute the external
compiler*? According to compiler-plugin source in this case javac returns
nonzero but mvn can't extract error information (alas mvn appears to eat
the javac error code in this situation)-
JavacCompiler.Java.
I know that Mvn has issues parsing java 7 output and I tried running java
manually but I can't reproduce the error.

I'm using mvn303, compiler plugin 2.5.1 and java 1.7 07.

   - mvn clean compile -X - *fails with error*
   - copy paste mvn's failed /bin/sh for javac invocation - *sh+javac
   completes without an error code*

Let me know if you have any ideas on how to handle this situation.

Thanks

Peter

`[ERROR] /bin/sh -c cd /myproj/modules/memory &&
/usr/java/jdk1.7.0_07/jre/../bin/javac
@/myproj/modules/memory/target/classes/org.codehaus.plexus.compiler.javac.JavacCompiler4013958444740287519arguments
-J-Xmx512m -J-Xms512m [ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project memory: Fatal error compiling at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
... ...

org.codehaus.plexus.compiler.javac.JavacCompiler.compileOutOfProcess(JavacCompiler.java:488)
at
org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:157)`


-- 
Peter Kahn
citizenk...@gmail.com
http://www.google.com/profiles/citizenkahn
Awareness - Intention - Action

Re: buildnumber-maven-plugin question regarding useLastCommittedRevision parameter

[Laird Nelson]

On Wed, Sep 19, 2012 at 11:30 AM, Laird Nelson  wrote:

> There is a parameter in buildnumber-maven-plugin that is named
> useLastCommittedRevision (
> http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html#useLastCommittedRevision).
>  Its default is false.  Why on earth would this be defaulted to false?
>  Why would you EVER set this to false?  In my scenario above, wouldn't
> this result in a build number of 262, not 271?  If I were to check out
> revision 262 of my project, then, I wouldn't get the change made to
> persistence.xml in revision 271 of the filetree.  YOW!  I *must* be
> misunderstanding something.
>

It turns out I am...and I am not.  I *am* misunderstanding the purpose of
the useLastCommittedRevision parameter (I still don't really know why you'd
set this one way or the other).  I am NOT misunderstanding that unless you
are careful you can end up with a build number being installed into your
product that will not in fact let you recover it.

The default setting that is really causing things to break is the doUpdate
parameter (
http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html#doUpdate)
which by default is false.  It turns out (unsurprisingly) that a commit
deep down in a working directory tree will not update the Subversion
metadata of the parent directories (after all, how could it?).
 Consequently until the next svnupdate any results reported by svn info are
basically stale.  Since buildnumber-maven-plugin uses svn info, which reads
local metadata unless it is told otherwise, then unless you can be sure
that your working directory has been updated you don't know whether that
build number will be correct or not.

Fortunately you can of course tell the plugin to always do an update by
setting the doUpdate parameter to true.

I hope this helps someone else out.

Best,
Laird

-- 
http://about.me/lairdnelson

buildnumber-maven-plugin question regarding useLastCommittedRevision parameter

[Laird Nelson]

I really hope this is an intelligent question.  :-)  It really does concern
the buildnumber-maven-plugin if you have the patience to get through this
message.  Thanks in advance.

I have a Subversion repository and a multi-module Maven project underneath
it.

When I do svn info from the root, let's say it tells me the revision is 262:

$ svn info
Path: .
URL: https://gobbledegook/foobar/branches/production
Repository Root: https://gobbledegook/foobar
Repository UUID: 8516f59a-58ba-46b5-a8ae-665e080df334
Revision: 262
Node Kind: directory
Schedule: normal
Last Changed Author: ljnelson
Last Changed Rev: 262
Last Changed Date: 2012-09-04 01:52:01 -0700 (Tue, 04 Sep 2012)


Now this is obviously information about this particular directory, and does
not give me any information about whether or not there are other revisions
that have taken place.  (Side question for Subversion experts: in this
case, would the Revision and Last Changed Rev ever diverge?)

If I commit a file waay down in the repo somewhere, let's say it
results in revision 271:

$ svn info persistence.xml
Path: persistence.xml
Name: persistence.xml
URL:
https://gobbledegook/foobar/branches/production/gewgaw-config/src/main/resources/META-INF/persistence.xml
Repository Root: https://gobbledegook/foobar
Repository UUID: 8516f59a-58ba-46b5-a8ae-665e080df334
Revision: 271
Node Kind: file
Schedule: normal
Last Changed Author: ljnelson
Last Changed Rev: 271
Last Changed Date: 2012-09-19 10:46:40 -0700 (Wed, 19 Sep 2012)
Text Last Updated: 2012-09-19 09:02:38 -0700 (Wed, 19 Sep 2012)
Checksum: e83459dca2f34a9c02883e8cb2031717


So obviously svn info from the root will not give me the number of the
filetree's most recent revision--it will only examine local metadata for
the directory itself in which it is run.

I can of course also run svnversion from the root, which confirms that the
latest revision is 271:

$ svnversion
262:271


OK, now out of Subversion land and into buildnumber-maven-plugin land.

There is a parameter in buildnumber-maven-plugin that is named
useLastCommittedRevision (
http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html#useLastCommittedRevision).
 Its default is false.  Why on earth would this be defaulted to false?  Why
would you EVER set this to false?  In my scenario above, wouldn't this
result in a build number of 262, not 271?  If I were to check out revision
262 of my project, then, I wouldn't get the change made to
persistence.xmlin revision
271 of the filetree.  YOW!  I *must* be misunderstanding something.

I'm trying to understand the rationale here more than anything (I'm aware I
can set the parameter to true).

Best,
Laird

-- 
http://about.me/lairdnelson

Re: strategy for incorporating private jars into a project

[Anthony Dahanne]

you could do that...(not leveraging maven at all and writing custom
svn related scripts)
but you could also go the suggested "push snapshots to repo" way,
keeping a large snapshots history... (btw snapshots are tagged with a
timestamp)

On Wed, Sep 19, 2012 at 1:30 PM, mlandman99  wrote:
> The suggestion (automatically upload to local repo) sounds like a good one,
> though I thought of a different solution that I'd like your opinion on:
>
> This project is used for running integration-level regression tests. The
> project is checked into source control (SVN).
>
> Conceivably, I may have a need to run the project tomorrow against an older
> version of code. If I were to do this, I'd want to run with the same version
> of the internal jars that I had used at that date.
>
> If I were to tell SVN to load the project as of date/label x (might be a
> release from 6 months ago..) -- and then run the project, I wouldn't want to
> take the latest version of those internal jars, I'd want to use the version
> that I used back at that date.
>
> To that end, I was thinking of creating a subdirectory within the project
> inside SVN reserved for holding those internal jars. This way, whenever I
> revert the project back to SVN version , I'll be assured I'm using those
> same version of those same internal jars that I had originally used on that
> date/label.
>
> To ensure I'm using the latest version (when I'm trying to run 'latest'), I
> could write a script to auto-commit those jars to the subdirectory of my
> project within SVN, overwriting the previous version. In reality it seems
> very similar to the suggestion you had, but it's utilizing SVN to house
> those artifacts instead of the local nexus repo.
>
> What are your thoughts on this?
>
> If I were to do this, what would the proper configuration be for Maven, i.e.
> to treat this special subdirectory as a location for retrieving artifacts,
> and to ensure that it's not cached, so that when I build, it will always use
> the version in that directory?
>
> Thanks for your help. I'm fairly new at this and appreciate the guidance.
>
>
>
>
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5722573.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: strategy for incorporating private jars into a project

[mlandman99]

The suggestion (automatically upload to local repo) sounds like a good one,
though I thought of a different solution that I'd like your opinion on:

This project is used for running integration-level regression tests. The
project is checked into source control (SVN).

Conceivably, I may have a need to run the project tomorrow against an older
version of code. If I were to do this, I'd want to run with the same version
of the internal jars that I had used at that date.

If I were to tell SVN to load the project as of date/label x (might be a
release from 6 months ago..) -- and then run the project, I wouldn't want to
take the latest version of those internal jars, I'd want to use the version
that I used back at that date.

To that end, I was thinking of creating a subdirectory within the project
inside SVN reserved for holding those internal jars. This way, whenever I
revert the project back to SVN version , I'll be assured I'm using those
same version of those same internal jars that I had originally used on that
date/label.

To ensure I'm using the latest version (when I'm trying to run 'latest'), I
could write a script to auto-commit those jars to the subdirectory of my
project within SVN, overwriting the previous version. In reality it seems
very similar to the suggestion you had, but it's utilizing SVN to house
those artifacts instead of the local nexus repo.

What are your thoughts on this?

If I were to do this, what would the proper configuration be for Maven, i.e.
to treat this special subdirectory as a location for retrieving artifacts,
and to ensure that it's not cached, so that when I build, it will always use
the version in that directory?

Thanks for your help. I'm fairly new at this and appreciate the guidance.




--
View this message in context: 
http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5722573.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: strategy for incorporating private jars into a project

[Baptiste MATHUS]

+1.
Seems to me it's the only sensible way to protect you from.outside behaving
badly.
I would write some script that check hashes, and upload
(deploy:deploy-file) the new binary if different from the last version.

Using any solution that would directly use the binaries on the network
share is just the first step on the road to hell :).

Cheers.
Le 19 sept. 2012 17:10, "Anthony Dahanne"  a
écrit :

> hello,
> why don't you push those private jars as snapshot versions into your
> local nexus ?
> Then in your build, use something like -U to make sure maven grabs the
> latest snapshots.
> Anthony
>
> On Wed, Sep 19, 2012 at 11:04 AM, mlandman99  wrote:
> > Hi,
> >
> > My java project has several dependencies, both external (i.e. in the
> public
> > repo) and private (built by our own company). It's a QA project, that
> can be
> > run locally in Eclipse, and also runs on a CI server (teamcity). When it
> > 'builds', it runs then maven phase: "integration-test", which then runs
> > testNG tests within my classes. So far so good.
> >
> > Unfortunately the private jars that it uses are not under any sort of
> > control. They are built by a different team in my company, and are
> placed in
> > an available network-share, but that's it. They don't seem to be properly
> > 'versioned', and are not placed in any local (nexus) repository, unless I
> > manually put them there.
> >
> > For running nightly automated testing, I want to ensure I always utilize
> the
> > most recent version of those private jars. So far, I've manually placed a
> > version of them in a local nexus repo, and they are successfully pulled
> down
> > when teamcity runs the build. But I don't have a way of getting the
> nightly
> > builds up inside that nexus repo. Even if I did, they would always just
> be
> > "version 1.0" and probably won't be re-downloaded anyway.
> >
> > So... I'm looking for suggestions re: a strategy on how to *ensure* that
> > each time my project is built, that it properly grabs the new version of
> > those private jars, of which the only reliable way to access them is in a
> > network share drive. The other public jars are successfully managed by
> > maven.
> >
> > Is there a way to use Maven to help me pull in these private jars that
> exist
> > on a network share? If anyone has any suggestions on a strategy re: how I
> > can proceed, I'd appreciate it!
> >
> > Thanks!
> >
> >
> >
> >
> > --
> > View this message in context:
> http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524.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: strategy for incorporating private jars into a project

[Anthony Dahanne]

hello,
why don't you push those private jars as snapshot versions into your
local nexus ?
Then in your build, use something like -U to make sure maven grabs the
latest snapshots.
Anthony

On Wed, Sep 19, 2012 at 11:04 AM, mlandman99  wrote:
> Hi,
>
> My java project has several dependencies, both external (i.e. in the public
> repo) and private (built by our own company). It's a QA project, that can be
> run locally in Eclipse, and also runs on a CI server (teamcity). When it
> 'builds', it runs then maven phase: "integration-test", which then runs
> testNG tests within my classes. So far so good.
>
> Unfortunately the private jars that it uses are not under any sort of
> control. They are built by a different team in my company, and are placed in
> an available network-share, but that's it. They don't seem to be properly
> 'versioned', and are not placed in any local (nexus) repository, unless I
> manually put them there.
>
> For running nightly automated testing, I want to ensure I always utilize the
> most recent version of those private jars. So far, I've manually placed a
> version of them in a local nexus repo, and they are successfully pulled down
> when teamcity runs the build. But I don't have a way of getting the nightly
> builds up inside that nexus repo. Even if I did, they would always just be
> "version 1.0" and probably won't be re-downloaded anyway.
>
> So... I'm looking for suggestions re: a strategy on how to *ensure* that
> each time my project is built, that it properly grabs the new version of
> those private jars, of which the only reliable way to access them is in a
> network share drive. The other public jars are successfully managed by
> maven.
>
> Is there a way to use Maven to help me pull in these private jars that exist
> on a network share? If anyone has any suggestions on a strategy re: how I
> can proceed, I'd appreciate it!
>
> Thanks!
>
>
>
>
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524.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

strategy for incorporating private jars into a project

[mlandman99]

Hi,

My java project has several dependencies, both external (i.e. in the public
repo) and private (built by our own company). It's a QA project, that can be
run locally in Eclipse, and also runs on a CI server (teamcity). When it
'builds', it runs then maven phase: "integration-test", which then runs
testNG tests within my classes. So far so good.

Unfortunately the private jars that it uses are not under any sort of
control. They are built by a different team in my company, and are placed in
an available network-share, but that's it. They don't seem to be properly
'versioned', and are not placed in any local (nexus) repository, unless I
manually put them there.

For running nightly automated testing, I want to ensure I always utilize the
most recent version of those private jars. So far, I've manually placed a
version of them in a local nexus repo, and they are successfully pulled down
when teamcity runs the build. But I don't have a way of getting the nightly
builds up inside that nexus repo. Even if I did, they would always just be
"version 1.0" and probably won't be re-downloaded anyway.

So... I'm looking for suggestions re: a strategy on how to *ensure* that
each time my project is built, that it properly grabs the new version of
those private jars, of which the only reliable way to access them is in a
network share drive. The other public jars are successfully managed by
maven.

Is there a way to use Maven to help me pull in these private jars that exist
on a network share? If anyone has any suggestions on a strategy re: how I
can proceed, I'd appreciate it!

Thanks!




--
View this message in context: 
http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524.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: Maven: Creating a new phase

[Stephen Connolly]

On 18 September 2012 23:19, John Riedl  wrote:

> Stephen:
>
> Wow, nice detailed observations.
>
> Just to make sure everyone else catches something that I misread the
> first time: it's only if you don't specify any phase that you get the
> help text without the new phases included.  If you do specify a phase
> that maven is confused about (as in your example below), the phases
> show up in the help text, after the default phases, but before site
> and clean.
>
>
I had offered the content as an edit to your answer on SO but the reviewers
felt it was a comment, so instead it is a second answer


> Best,
> John
>
> On Tue, Sep 18, 2012 at 10:34 AM, Stephen Connolly
>  wrote:
> > There are some limits to this... perhaps due to some bugs in how Maven
> > handles this type of thing e.g.
> >
> > This requires Maven 3.0 or newer to work. When you try to use this in
> Maven
> > 2.x you will get a error such as:
> >
> > $ mvn eval
> > [INFO] Scanning for projects...
> > [INFO]
> 
> > [ERROR] BUILD FAILURE
> > [INFO]
> 
> > [INFO] Invalid task 'eval': you must specify a valid lifecycle phase, or
> a goal
> > in the format plugin:goal or
> pluginGroupId:pluginArtifactId:pluginVersion:goal
> > [INFO]
> 
> > [INFO] For more information, run Maven with the -e switch
> > [INFO]
> 
> > [INFO] Total time: < 1 second
> > [INFO] Finished at: Tue Sep 18 15:58:12 IST 2012
> > [INFO] Final Memory: 2M/81M
> > [INFO]
> 
> >
> > At least as of Maven 3.0.4 it does not list these phases in the help text
> > when you invoke Maven without a goal or phase:
> >
> > $ mvn
> > [INFO] Scanning for projects...
> > [INFO]
> 
> > [INFO] BUILD FAILURE
> > [INFO]
> 
> > [INFO] Total time: 0.224s
> > [INFO] Finished at: Tue Sep 18 16:03:20 IST 2012
> > [INFO] Final Memory: 2M/81M
> > [INFO]
> 
> > [ERROR] No goals have been specified for this build. You must specify a
> valid
> > lifecycle phase or a goal in the format : or
> > :[:]:.
> Available
> > lifecycle phases are: validate, initialize, generate-sources,
> process-sources,
> > generate-resources, process-resources, compile, process-classes,
> > generate-test-sources, process-test-sources, generate-test-resources,
> > process-test-resources, test-compile, process-test-classes, test,
> > prepare-package, package, pre-integration-test, integration-test,
> > post-integration-test, verify, install, deploy, pre-clean, clean,
> post-clean,
> > pre-site, site, post-site, site-deploy. -> [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/NoGoalSpecifiedException
> >
> > In a multi-module build you can end up screwed.
> >
> > Consider the following two extenions modules:
> > Extension 1
> >
> > 
> >   
> > 
> >   org.apache.maven.lifecycle.mapping.LifecycleMapping
> >   fancy
> >   
> > org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
> >   
> > 
> > 
> >   org.apache.maven.lifecycle.Lifecycle
> >
> org.apache.maven.lifecycle.Lifecycle
> >   fancy
> >   
> >  fancy
> >  
> > fancy
> >  
> >  
> > org.codehaus.mojo:rpm-maven-plugin:version
> >  
> >   
> > 
> >   
> > 
> >
> > Extension 2
> >
> > 
> >   
> > 
> >   org.apache.maven.lifecycle.mapping.LifecycleMapping
> >   poncy
> >   
> > org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
> >   
> > 
> > 
> >   org.apache.maven.lifecycle.Lifecycle
> >
> org.apache.maven.lifecycle.Lifecycle
> >   poncy
> >   
> >  poncy
> >  
> > poncy
> > fancy
> >  
> >  
> >
> org.apache.maven.plugins:maven-enforcer-plugin:display-info
> >
> org.codehaus.mojo:build-helper-maven-plugin:parse-version
> >  
> >   
> > 
> >   
> > 
> >
> > Parent pom
> >
> > 
> > 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
> >
> >   localdomain.localhost
> >