Re: Activation based on maven version?

[Anders Hammar]

No, this is not possible for the moment as far as I know (thus, my ticket).
This might also be possible to implement without changing the pom schema,
but there might be some clever solution.

/Anders
On Wed, Aug 25, 2010 at 00:59, Andrew Robinson andrew.rw.robin...@gmail.com
 wrote:

 I would like to perform an activation based on maven version (for my
 needs I would like to know maven  2.0.8). Is there any way to do
 this?

 I noticed this has been filed and not resolved:
 http://jira.codehaus.org/browse/MNG-4760

 Basically I want to change a plugin to use a certain version for maven
 2.2.1 but not 2.0.8.

 Thanks,
 Andrew

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

Re: how to best manage versions for a large common set of dependencies

[Anders Hammar]

I don't think that I would call Ron's solution a best-practice (I see issues
with transitive dependencies). If you want something as simple as just
adding one dependency, you should create a pom project that groups these
dependencies. Tim explains this in this blog post:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

However, be aware that there are drawbacks with this solution. For one, the
mvn dependency:analyze won't work as the dependencies go one the wrong
level. The import pom solution that Stephen suggests does not have this
limitation, which is very nice.

/Anders

On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
rwhee...@artifact-software.comwrote:

  This is a common problem in a portal environment or SOA architecture where
 many webapps are generated.
 We solved this by creating a set of projects that create sets of jars that
 group together a bunch of jars into one massive jar.

 For example, we have a spring-mysql-hibernate-tomcat project that creates
 an aggregated jar with all of the libraries included in this set of
 projects.
 The POM that manages this project has all the version numbers so the parent
 pom of all of the modules only specifies the application version and the
 module only depends on our set of aggregated POMs.

 If you want to change the version of a Hibernate library you only have to
 change it in one place.
 The POMs that create individual application artifacts do not know anything
 about the version of Hibernate, they only depend on the current
 ($project.version) version of the application to get all the right bits and
 pieces of spring, mysql, hibernate and tomcat.

 This really simplifies the management of individual portlets or web
 services.
 They call on one parent POM that specifies the {$project.version} and use
 this variable in the dependency for spring-mysql-hibernate-tomcat, jsf, CXF,
 etc.
 This means that a module's POM is very stable and only has 4 or 5
 dependencies.
 We also deploy the aggregated jars into the Tomcat shared library.

 This makes the webapps very small and reduces the number of choices that a
 developer has to make about third party jars.

 Ron




 On 24/08/2010 5:54 PM, Zac Thompson wrote:

 I've racked my brain to come up with an ideal solution to this,
 without success, so I'm throwing myself on the mercy of the group.
 Any and all advice is greatly appreciated.

 I have a project with many modules that are all released together;
 let's say they're in group ca.zac.A.  The parent pom (also the
 aggregator) for the group defines dependencyManagement for all the
 child poms so that keeping versions consistent within the group and
 releasing them together is easy.  So far, so good.

 But other projects might depend on a subset of the group, or have
 transitive dependencies on them, so I list the whole set of ca.zac.A
 modules in the dependencyManagement section of each such project: I
 want to be sure of keeping the versions consistent and known, and
 sometimes Maven's resolution ends up choosing mixed versions.  But
 adding the whole set means I end up duplicating a large block of the
 POM in multiple projects.  And if I add a new module that might get
 transitively included, then I have to update multiple places.  I am
 looking for a way to centralize this information.

 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
 properties to affect transitive dependencies is not likely to happen
 any time soon, and I wholeheartedly agree that it's a bad idea anyway.

 2) The idea of inheriting from the ca.zac.A parent pom worked with
 maven 2.1.0, but not well for other versions (and it smells bad
 anyway).

 3) I *could* list them all in dependencyManagement in my
 organizational parent pom, with the version controlled by a single
 property, but then I'd have to update it whenever a new module is
 added to ca.zac.A.  Having such a pom list a sizable set of my
 projects is probably workable, but it feels like I'm abusing it.

 4) Multiple inheritance is not supported nor desired, and I understand
 that the planned mixin capability won't be around until post-3.0.  I
 could have an intermediate parent pom, with just the
 dependencyManagement entries for my group, but in fact, I have more
 than one such set.  So I'd have to put all such groups in one pom, and
 update it whenever ca.zac.A or .B or .C have a new module.  This is
 probably my best option, but it still feels less than ideal: I'd
 rather be able to update a discrete place for each group.  In
 practical terms, this isn't much different than putting it in the org
 parent, because I'd have to use this as the parent for most projects
 anyway.

 Am I stuck for now?  Is there some other option I'm just not seeing?

 What I find myself wishing for is something like the following, and
 just have it apply to all the artifacts in the group (note that I
 would only ever want to do it for a groupId that I controlled):

 dependencyManagement
   

How can I write the complete environment of a maven build into a file for later reference / debugging?

[Heix, Andreas]

Hi,

we use mvn on both local developer's machines as well as some central CI 
servers and machines reserved to do the real release builds. This means 
different OS, Nexus instances used as proxy and so on.

When we encounter the it works on my machine, it takes us some time to spot 
the differences which might be the cause for this. It seems that the class 
org.apache.maven.execution.MavenSession contains many of the interesting 
parameters, but I have not found a way to dump its status so we could compare 
it with another MavenSession instance from another machine.

I did some reverse engineering, which does the job for us, but it is - well, 
just reverse engineering. Especially the filtering is really depending on the 
non-API internals of the classes. Is there a nicer solution available from the 
Maven core?

Thanks and kind regards
Andreas




public static void dumpMavenSessionAsXML(MavenSession session, 
OutputStream outputStream, boolean filtered) {

XStream xstream = new XStream(new DomDriver(UTF8_ENCODING));
if (filtered) {
xstream.omitField(DefaultPlexusContainer.class, 
containerContext);
xstream.omitField(DefaultPlexusContainer.class, 
classWorld);
xstream.omitField(DefaultPlexusContainer.class, 
componentRegistry);
xstream.omitField(DefaultPlexusContainer.class, 
containerRealm);
xstream.omitField(DefaultPlexusContainer.class, 
loggerManager);

xstream.omitField(MavenSession.class, 
pluginContextsByProjectAndPluginKey);
xstream.omitField(MavenSession.class, result);
xstream.omitField(MavenProject.class, 
mavenProjectBuilder);
xstream.omitField(MavenProject.class, 
repositorySystem);
xstream.omitField(MavenProject.class, 
projectBuilderConfiguration);

xstream.omitField(DefaultMavenExecutionRequest.class, 
localRepository);
xstream.omitField(DefaultMavenExecutionRequest.class, 
repositoryCache);
xstream.omitField(DefaultMavenExecutionRequest.class, 
transferListener);
xstream.omitField(DefaultMavenExecutionRequest.class, 
projectBuildingRequest);
xstream.omitField(DefaultMavenExecutionRequest.class, 
executionListener);
}   

xstream.toXML(session, outputStream);
}




Pflichtangaben/Mandatory Disclosure Statements: 
http://www.sap.com/company/legal/impressum.epx
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige 
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich 
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung 
oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie 
uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise 
confidential information. If you have received this e-mail in error, you are 
hereby notified that any review, copying, or distribution of it is strictly 
prohibited. Please inform us immediately and destroy the original transmittal. 
Thank you for your cooperation.


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

Re: Reopen MECLIPSE-36

[Stevo Slavić]

Great, thanks!

Regards,
Stevo.

On Wed, Aug 25, 2010 at 6:39 AM, Barrie Treloar baerr...@gmail.com wrote:

 On Tue, Aug 24, 2010 at 6:28 PM, Stevo Slavić ssla...@gmail.com wrote:
  Hello Apache Maven users,
 
  Can someone of the Apache Maven developers please reopen the
  MECLIPSE-36http://jira.codehaus.org/browse/MECLIPSE-36issue, it is
  still present (in maven-eclipse-plugin:2.8).

 I've duplicated this as http://jira.codehaus.org/browse/MECLIPSE-667
 and marked it as a regression.

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

maven-dependency-plugin fail when unpack or copy give WARNING

[eldad_ak]

Hi all,
Is there a way to fail the copy or unpack if they give warnings?
Much like in this case: 
http://maven.apache.org/plugins/maven-dependency-plugin/examples/failing-the-build-on-dependency-analysis-warnings.html
http://maven.apache.org/plugins/maven-dependency-plugin/examples/failing-the-build-on-dependency-analysis-warnings.html
 

But - I want to fail the build if the warning comes during the actual unpack
or copy (like when destination files are locked or read-only and cannot be
overwritten).

Thx.
Eldad
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/maven-dependency-plugin-fail-when-unpack-or-copy-give-WARNING-tp2652324p2652324.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: Using Subversion and Maven

[Nicola Musatti]

Did you install an Eclipse Subversion plugin, such as Subversive or 
Subclipse? This doesn't seem to have much to do with Maven...


Cheers,
Nicola Musatti

Timothy Mcginnis wrote:

Well, I probably should have posted this in the M2Eclipse list (which I
have done since then).  Previously when using cvs it just used the client
in Eclipse, but when I tried to do the same with subversion it gave me
this error.

Tim McGinnis
717 720-1962
Web Development
AES/PHEAA



From:
Wayne Faywayne...@gmail.com
To:
Maven Users Listusers@maven.apache.org
Date:
08/24/2010 03:04 PM
Subject:
Re: Using Subversion and Maven



   

with Subversion.  I am getting the error 'svn' is not recognized as an
internal or external command.  From what I can find on google I
 

actually
   

need to have svn installed separately from Maven.  Is this correct?
 

Yes.

What causes you to assume anything else? Is there some documentation
that should be updated or fixed? I've seen this question multiple
times on this list.

Wayne

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





==
This message contains privileged and confidential information intended for the 
above addressees only.  If you
receive this message in error please delete or destroy this message and/or 
attachments.

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging
in the unauthorized use of this message.
==

   



Chi riceve il presente messaggio e' tenuto a verificare se lo stesso non gli
sia pervenuto per errore. In tal caso e' pregato di avvisare immediatamente
il mittente e, tenuto conto delle responsabilita' connesse all'indebito
utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
contenute, voglia cancellare l'originale e distruggere le varie copie o
stampe.

The receiver of this message is required to check if he/she has received it
erroneously. If so, the receiver is requested to immediately inform the
sender and - in consideration of the responsibilities arising from undue use
and/or disclosure of the message and/or the information contained therein -
destroy the original message and any copy or printout thereof. 



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

Re: How can I write the complete environment of a maven build into a file for later reference / debugging?

[eldad_ak]

Hi,
I suggest adding the maven-antrun-plugin and using the echoporperties task
and then an exec task where you simply call 'set' (on windows) or 'env'
and 'set' (on unix) and redirect the output as needed. It's not so fancy,
but it gets the job done.

Eldad
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/How-can-I-write-the-complete-environment-of-a-maven-build-into-a-file-for-later-reference-debugging-tp2652250p2652398.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: Using Subversion and Maven

[Martin Schayna]

It depends on actual pom.xml. Some Maven plugins operate with Subversion 
through 'svn' comannd line, for example buildnumber-maven-plugin (my 
favorite) is called during each build and it emits errors like this if 
there is no svn client installed.


Martin Schayna


On 08/25/2010 11:03 AM, Nicola Musatti wrote:
Did you install an Eclipse Subversion plugin, such as Subversive or 
Subclipse? This doesn't seem to have much to do with Maven...


Cheers,
Nicola Musatti

Timothy Mcginnis wrote:

Well, I probably should have posted this in the M2Eclipse list (which I
have done since then).  Previously when using cvs it just used the 
client

in Eclipse, but when I tried to do the same with subversion it gave me
this error.

Tim McGinnis
717 720-1962
Web Development
AES/PHEAA



From:
Wayne Faywayne...@gmail.com
To:
Maven Users Listusers@maven.apache.org
Date:
08/24/2010 03:04 PM
Subject:
Re: Using Subversion and Maven

with Subversion.  I am getting the error 'svn' is not recognized as an
internal or external command.  From what I can find on google I

actually

need to have svn installed separately from Maven.  Is this correct?

Yes.

What causes you to assume anything else? Is there some documentation
that should be updated or fixed? I've seen this question multiple
times on this list.

Wayne




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

XML node attributes when writing a custom mojo

[Gajo Csaba]

Hello there!

Is it possible to design a custom Maven plugin in such a way that the 
nodes in its configuration use xml attributes? For example, instead of


configure
include
namesomefile.txt/name
/include
/configure

I would like to have

configure
include name=somefile.txt/
/configure

Is there some built-in support for this in Maven 2?

Thanks, Csaba



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

Using a Veloctity template in a custom Maven report

[jasnook]

Hi,

I am trying to write a report plugin for Maven which will run during
the 'site' stage in the lifecycle.  The plugin needs to be able to use
a Velocity template to create a HTML file.

I have created a Mojo which extends AbstractMavenReport and within
that I have

/**
 * @component
 */
private VelocityComponent velocityComponent;

so that I can get hold of the Plexus velocity component.  I am
currently passing this into a method and using this as:

public void createReport(VelocityComponent velocityComponent) throws
Exception {

VelocityContext context = new VelocityContext();
// put stuff into the context.

Template template = null;
try {
Properties props = new Properties();
props.setProperty(resource.loader,
classpath);   //makes no difference if set or
not

props.setProperty(classpath.resource.loader.class,
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader); //
makes no difference if set or not
velocityComponent.getEngine().init(props);
template =
velocityComponent.getEngine().getTemplate(report.vm);
}
catch (ResourceNotFoundException rnfe) {
System.out.println(Example : error : cannot find template
report.vm);
}
catch (ParseErrorException pee) {
System.out.println(Example : Syntax error in template
report.vm:  + pee);
}
BufferedWriter writer = writer = new BufferedWriter(
new OutputStreamWriter(System.out));  //testing by
writing to the screen
if (template != null) {
template.merge(context, writer);
}
writer.flush();
writer.close();
}

I am getting a ResourceNotFoundException when running this.  Where do
I need to put the vm file so that it is picked up or how should I be
using the velocitycomponent?

btw.  I am using Maven 2.2.1.

Thanks,
Jacqui 
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Using-a-Veloctity-template-in-a-custom-Maven-report-tp2652484p2652484.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: Using a Veloctity template in a custom Maven report

[Gajo Csaba]

To build a website with mvn site, you need to put your custom .vm file 
somewhere in your project directory, and then in your pom.xml configure 
the maven-site-plugin to use that .vm file.


build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.1.1/version
configuration
templateFile${basedir}/src/my-custom-template.vm/templateFile
/configuration
/plugin

Try this and maybe the velocity component will just work.

Cheers, Csaba


On 08/25/2010 12:54 PM, jasnook wrote:

Hi,

I am trying to write a report plugin for Maven which will run during
the 'site' stage in the lifecycle.  The plugin needs to be able to use
a Velocity template to create a HTML file.

I have created a Mojo which extends AbstractMavenReport and within
that I have

/**
  * @component
  */
 private VelocityComponent velocityComponent;

so that I can get hold of the Plexus velocity component.  I am
currently passing this into a method and using this as:

public void createReport(VelocityComponent velocityComponent) throws
Exception {

 VelocityContext context = new VelocityContext();
 // put stuff into the context.

 Template template = null;
 try {
 Properties props = new Properties();
 props.setProperty(resource.loader,
classpath);   //makes no difference if set or
not

props.setProperty(classpath.resource.loader.class,
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader); //
makes no difference if set or not
 velocityComponent.getEngine().init(props);
 template =
velocityComponent.getEngine().getTemplate(report.vm);
 }
 catch (ResourceNotFoundException rnfe) {
 System.out.println(Example : error : cannot find template
report.vm);
 }
 catch (ParseErrorException pee) {
 System.out.println(Example : Syntax error in template
report.vm:  + pee);
 }
 BufferedWriter writer = writer = new BufferedWriter(
 new OutputStreamWriter(System.out));  //testing by
writing to the screen
 if (template != null) {
 template.merge(context, writer);
 }
 writer.flush();
 writer.close();
 }

I am getting a ResourceNotFoundException when running this.  Where do
I need to put the vm file so that it is picked up or how should I be
using the velocitycomponent?

btw.  I am using Maven 2.2.1.

Thanks,
Jacqui
   



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

Re: Using Subversion and Maven

[Timothy Mcginnis]

I mis-spoke when I said it just used the client in Eclipse.  I think cvs 
uses a client packaged with one of the maven-scm-provider-cvs-??? jars. 
Although I have not looked into the source code to verify this.

I just assumed the subversion provider would do the same.  Seems like it 
doesn't due to a licensing issue from what someone else said.

Tim McGinnis
717 720-1962
Web Development
AES/PHEAA



From:
Nicola Musatti nicola.musa...@objectway.it
To:
Maven Users List users@maven.apache.org
Date:
08/25/2010 05:04 AM
Subject:
Re: Using Subversion and Maven



Did you install an Eclipse Subversion plugin, such as Subversive or 
Subclipse? This doesn't seem to have much to do with Maven...

Cheers,
Nicola Musatti

Timothy Mcginnis wrote:
 Well, I probably should have posted this in the M2Eclipse list (which I
 have done since then).  Previously when using cvs it just used the 
client
 in Eclipse, but when I tried to do the same with subversion it gave me
 this error.

 Tim McGinnis
 717 720-1962
 Web Development
 AES/PHEAA



 From:
 Wayne Faywayne...@gmail.com
 To:
 Maven Users Listusers@maven.apache.org
 Date:
 08/24/2010 03:04 PM
 Subject:
 Re: Using Subversion and Maven



 
 with Subversion.  I am getting the error 'svn' is not recognized as an
 internal or external command.  From what I can find on google I
 
 actually
 
 need to have svn installed separately from Maven.  Is this correct?
 
 Yes.

 What causes you to assume anything else? Is there some documentation
 that should be updated or fixed? I've seen this question multiple
 times on this list.

 Wayne

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





 
==
 This message contains privileged and confidential information intended 
for the above addressees only.  If you
 receive this message in error please delete or destroy this message 
and/or attachments.

 The sender of this message will fully cooperate in the civil and 
criminal prosecution of any individual engaging
 in the unauthorized use of this message.
 
==

 


Chi riceve il presente messaggio e' tenuto a verificare se lo stesso non 
gli
sia pervenuto per errore. In tal caso e' pregato di avvisare 
immediatamente
il mittente e, tenuto conto delle responsabilita' connesse all'indebito
utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
contenute, voglia cancellare l'originale e distruggere le varie copie o
stampe.

The receiver of this message is required to check if he/she has received 
it
erroneously. If so, the receiver is requested to immediately inform the
sender and - in consideration of the responsibilities arising from undue 
use
and/or disclosure of the message and/or the information contained therein 
-
destroy the original message and any copy or printout thereof. 


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





==
This message contains privileged and confidential information intended for the 
above addressees only.  If you
receive this message in error please delete or destroy this message and/or 
attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging
in the unauthorized use of this message.
==

Re: XML node attributes when writing a custom mojo

[Stephen Connolly]

yes, there is, I am at a loss to recall how, but I'd have a look at the
maven-antrun-plugin as it has to be doing at least one way of implementing
it.

another starting point is the maven-enforcer-plugin as it does custom
parsing of the configuration section

2010/8/25 Gajo Csaba csaba.g...@cosylab.com

 Hello there!

 Is it possible to design a custom Maven plugin in such a way that the nodes
 in its configuration use xml attributes? For example, instead of

 configure
 include
 namesomefile.txt/name
 /include
 /configure

 I would like to have

 configure
 include name=somefile.txt/
 /configure

 Is there some built-in support for this in Maven 2?

 Thanks, Csaba



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

Re: Using a Veloctity template in a custom Maven report

[jasnook]

Thanks for the very fast reply.  However, I was thinking more along the lines
of having a self contained plugin (as described here -
http://docs.codehaus.org/display/MAVENUSER/Write+your+own+report+plugin)
which contains the velocity files.

Then I could call it from my code as:

reporting
  plugins
plugin
  groupIdcustom-groupid/groupId
  artifactIdcustom-artifactid/artifactId
/plugin
  /plugins
/reporting

Cheers,
Jacqui
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Using-a-Veloctity-template-in-a-custom-Maven-report-tp2652484p2652550.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: activation by property versus properties/ versus releases versus integration tests

[Benson Margulies]

I don't know how interested they are in messing with their 'version 6'
branch, though some of us are glued to it at the moment. I can but
ask. I keep wishing that Maven itself had more ways that profile (b)
could turn off things from the base or a previous profile (a).

On Tue, Aug 24, 2010 at 10:54 PM, Wayne Fay wayne...@gmail.com wrote:
 problem. However, the maven-jetty-plugin lacks a 'skip' property. I

 Anyone got another suggestion?

 Add/request the skip property for m-jetty-p? Should be super simple to do.

 Wayne

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



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

Re: how to best manage versions for a large common set of dependencies

[Ron Wheeler]

 On 25/08/2010 2:45 AM, Anders Hammar wrote:

I don't think that I would call Ron's solution a best-practice (I see issues
with transitive dependencies).
Can you elaborate? We have not found any problems yet but perhaps we 
have been lucky.

We do pay attention to version conflicts while building the aggregate jars.
Are we missing something?


If you want something as simple as just
adding one dependency, you should create a pom project that groups these
dependencies. Tim explains this in this blog post:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

However, be aware that there are drawbacks with this solution. For one, the
mvn dependency:analyze won't work as the dependencies go one the wrong
level. The import pom solution that Stephen suggests does not have this
limitation, which is very nice.

/Anders

On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
rwhee...@artifact-software.comwrote:


  This is a common problem in a portal environment or SOA architecture where
many webapps are generated.
We solved this by creating a set of projects that create sets of jars that
group together a bunch of jars into one massive jar.

For example, we have a spring-mysql-hibernate-tomcat project that creates
an aggregated jar with all of the libraries included in this set of
projects.
The POM that manages this project has all the version numbers so the parent
pom of all of the modules only specifies the application version and the
module only depends on our set of aggregated POMs.

If you want to change the version of a Hibernate library you only have to
change it in one place.
The POMs that create individual application artifacts do not know anything
about the version of Hibernate, they only depend on the current
($project.version) version of the application to get all the right bits and
pieces of spring, mysql, hibernate and tomcat.

This really simplifies the management of individual portlets or web
services.
They call on one parent POM that specifies the {$project.version} and use
this variable in the dependency for spring-mysql-hibernate-tomcat, jsf, CXF,
etc.
This means that a module's POM is very stable and only has 4 or 5
dependencies.
We also deploy the aggregated jars into the Tomcat shared library.

This makes the webapps very small and reduces the number of choices that a
developer has to make about third party jars.

Ron




On 24/08/2010 5:54 PM, Zac Thompson wrote:


I've racked my brain to come up with an ideal solution to this,
without success, so I'm throwing myself on the mercy of the group.
Any and all advice is greatly appreciated.

I have a project with many modules that are all released together;
let's say they're in group ca.zac.A.  The parent pom (also the
aggregator) for the group defines dependencyManagement for all the
child poms so that keeping versions consistent within the group and
releasing them together is easy.  So far, so good.

But other projects might depend on a subset of the group, or have
transitive dependencies on them, so I list the whole set of ca.zac.A
modules in the dependencyManagement section of each such project: I
want to be sure of keeping the versions consistent and known, and
sometimes Maven's resolution ends up choosing mixed versions.  But
adding the whole set means I end up duplicating a large block of the
POM in multiple projects.  And if I add a new module that might get
transitively included, then I have to update multiple places.  I am
looking for a way to centralize this information.

1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
properties to affect transitive dependencies is not likely to happen
any time soon, and I wholeheartedly agree that it's a bad idea anyway.

2) The idea of inheriting from the ca.zac.A parent pom worked with
maven 2.1.0, but not well for other versions (and it smells bad
anyway).

3) I *could* list them all in dependencyManagement in my
organizational parent pom, with the version controlled by a single
property, but then I'd have to update it whenever a new module is
added to ca.zac.A.  Having such a pom list a sizable set of my
projects is probably workable, but it feels like I'm abusing it.

4) Multiple inheritance is not supported nor desired, and I understand
that the planned mixin capability won't be around until post-3.0.  I
could have an intermediate parent pom, with just the
dependencyManagement entries for my group, but in fact, I have more
than one such set.  So I'd have to put all such groups in one pom, and
update it whenever ca.zac.A or .B or .C have a new module.  This is
probably my best option, but it still feels less than ideal: I'd
rather be able to update a discrete place for each group.  In
practical terms, this isn't much different than putting it in the org
parent, because I'd have to use this as the parent for most projects
anyway.

Am I stuck for now?  Is there some other option I'm just not seeing?

What I find myself wishing for is something like the 

Re: how to best manage versions for a large common set of dependencies

[Anders Hammar]

What I was thinking of was that you could get transitive dependencies
included which are actually also included in your super-jar. As the
super-jar is of a different GA than the original/correct artifact, Maven
will have no chance to handle that but you need to exclude that manually. In
my experience, no normal Java developer will have a clue about this.

As the dependency grouping pom solves this issue I see it as a better Maven
solution. However, it will make your deployment to the server involve a
little bit more work as you need to copy more than one jar. But I assume you
have tools to do this so it shouldn't be an issue, right?

/Anders

On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
rwhee...@artifact-software.comwrote:

  On 25/08/2010 2:45 AM, Anders Hammar wrote:

 I don't think that I would call Ron's solution a best-practice (I see
 issues
 with transitive dependencies).

 Can you elaborate? We have not found any problems yet but perhaps we have
 been lucky.
 We do pay attention to version conflicts while building the aggregate jars.
 Are we missing something?


  If you want something as simple as just
 adding one dependency, you should create a pom project that groups these
 dependencies. Tim explains this in this blog post:

 http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

 However, be aware that there are drawbacks with this solution. For one,
 the
 mvn dependency:analyze won't work as the dependencies go one the wrong
 level. The import pom solution that Stephen suggests does not have this
 limitation, which is very nice.

 /Anders

 On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
 rwhee...@artifact-software.comwrote:

   This is a common problem in a portal environment or SOA architecture
 where
 many webapps are generated.
 We solved this by creating a set of projects that create sets of jars
 that
 group together a bunch of jars into one massive jar.

 For example, we have a spring-mysql-hibernate-tomcat project that creates
 an aggregated jar with all of the libraries included in this set of
 projects.
 The POM that manages this project has all the version numbers so the
 parent
 pom of all of the modules only specifies the application version and the
 module only depends on our set of aggregated POMs.

 If you want to change the version of a Hibernate library you only have to
 change it in one place.
 The POMs that create individual application artifacts do not know
 anything
 about the version of Hibernate, they only depend on the current
 ($project.version) version of the application to get all the right bits
 and
 pieces of spring, mysql, hibernate and tomcat.

 This really simplifies the management of individual portlets or web
 services.
 They call on one parent POM that specifies the {$project.version} and use
 this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
 CXF,
 etc.
 This means that a module's POM is very stable and only has 4 or 5
 dependencies.
 We also deploy the aggregated jars into the Tomcat shared library.

 This makes the webapps very small and reduces the number of choices that
 a
 developer has to make about third party jars.

 Ron




 On 24/08/2010 5:54 PM, Zac Thompson wrote:

  I've racked my brain to come up with an ideal solution to this,
 without success, so I'm throwing myself on the mercy of the group.
 Any and all advice is greatly appreciated.

 I have a project with many modules that are all released together;
 let's say they're in group ca.zac.A.  The parent pom (also the
 aggregator) for the group defines dependencyManagement for all the
 child poms so that keeping versions consistent within the group and
 releasing them together is easy.  So far, so good.

 But other projects might depend on a subset of the group, or have
 transitive dependencies on them, so I list the whole set of ca.zac.A
 modules in the dependencyManagement section of each such project: I
 want to be sure of keeping the versions consistent and known, and
 sometimes Maven's resolution ends up choosing mixed versions.  But
 adding the whole set means I end up duplicating a large block of the
 POM in multiple projects.  And if I add a new module that might get
 transitively included, then I have to update multiple places.  I am
 looking for a way to centralize this information.

 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
 properties to affect transitive dependencies is not likely to happen
 any time soon, and I wholeheartedly agree that it's a bad idea anyway.

 2) The idea of inheriting from the ca.zac.A parent pom worked with
 maven 2.1.0, but not well for other versions (and it smells bad
 anyway).

 3) I *could* list them all in dependencyManagement in my
 organizational parent pom, with the version controlled by a single
 property, but then I'd have to update it whenever a new module is
 added to ca.zac.A.  Having such a pom list a sizable set of my
 projects is probably workable, but it feels like 

Re: how to best manage versions for a large common set of dependencies

[Ron Wheeler]

 On 25/08/2010 9:07 AM, Anders Hammar wrote:

What I was thinking of was that you could get transitive dependencies
included which are actually also included in your super-jar. As the
super-jar is of a different GA than the original/correct artifact, Maven
will have no chance to handle that but you need to exclude that manually. In
my experience, no normal Java developer will have a clue about this.
The developers generally do not have to add any dependencies to their 
poms other than the libraries that we have agreed on.
This simplifies their lives since they do not have to worry about third 
party jars.
If there is a new library added to an individual module, the maven 
dependency hierarchy window identifies conflicts which can then be 
raised with the team to see how it should be resolved.


Ron

As the dependency grouping pom solves this issue I see it as a better Maven
solution. However, it will make your deployment to the server involve a
little bit more work as you need to copy more than one jar. But I assume you
have tools to do this so it shouldn't be an issue, right?

/Anders

On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
rwhee...@artifact-software.comwrote:


  On 25/08/2010 2:45 AM, Anders Hammar wrote:


I don't think that I would call Ron's solution a best-practice (I see
issues
with transitive dependencies).


Can you elaborate? We have not found any problems yet but perhaps we have
been lucky.
We do pay attention to version conflicts while building the aggregate jars.
Are we missing something?


  If you want something as simple as just

adding one dependency, you should create a pom project that groups these
dependencies. Tim explains this in this blog post:

http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

However, be aware that there are drawbacks with this solution. For one,
the
mvn dependency:analyze won't work as the dependencies go one the wrong
level. The import pom solution that Stephen suggests does not have this
limitation, which is very nice.

/Anders

On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
rwhee...@artifact-software.comwrote:

   This is a common problem in a portal environment or SOA architecture

where
many webapps are generated.
We solved this by creating a set of projects that create sets of jars
that
group together a bunch of jars into one massive jar.

For example, we have a spring-mysql-hibernate-tomcat project that creates
an aggregated jar with all of the libraries included in this set of
projects.
The POM that manages this project has all the version numbers so the
parent
pom of all of the modules only specifies the application version and the
module only depends on our set of aggregated POMs.

If you want to change the version of a Hibernate library you only have to
change it in one place.
The POMs that create individual application artifacts do not know
anything
about the version of Hibernate, they only depend on the current
($project.version) version of the application to get all the right bits
and
pieces of spring, mysql, hibernate and tomcat.

This really simplifies the management of individual portlets or web
services.
They call on one parent POM that specifies the {$project.version} and use
this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
CXF,
etc.
This means that a module's POM is very stable and only has 4 or 5
dependencies.
We also deploy the aggregated jars into the Tomcat shared library.

This makes the webapps very small and reduces the number of choices that
a
developer has to make about third party jars.

Ron




On 24/08/2010 5:54 PM, Zac Thompson wrote:

  I've racked my brain to come up with an ideal solution to this,

without success, so I'm throwing myself on the mercy of the group.
Any and all advice is greatly appreciated.

I have a project with many modules that are all released together;
let's say they're in group ca.zac.A.  The parent pom (also the
aggregator) for the group defines dependencyManagement for all the
child poms so that keeping versions consistent within the group and
releasing them together is easy.  So far, so good.

But other projects might depend on a subset of the group, or have
transitive dependencies on them, so I list the whole set of ca.zac.A
modules in the dependencyManagement section of each such project: I
want to be sure of keeping the versions consistent and known, and
sometimes Maven's resolution ends up choosing mixed versions.  But
adding the whole set means I end up duplicating a large block of the
POM in multiple projects.  And if I add a new module that might get
transitively included, then I have to update multiple places.  I am
looking for a way to centralize this information.

1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
properties to affect transitive dependencies is not likely to happen
any time soon, and I wholeheartedly agree that it's a bad idea anyway.

2) The idea of inheriting from the ca.zac.A parent pom worked 

Re: how to best manage versions for a large common set of dependencies

[Anders Hammar]

As long as you know about the drawbacks. It makes me remember all those
trouble free days of ant..

classpath
  fileset dir=lib
include name=**/*.jar/
  /fileset
/classpath

:-)

/Anders

On Wed, Aug 25, 2010 at 15:30, Ron Wheeler
rwhee...@artifact-software.comwrote:

  On 25/08/2010 9:07 AM, Anders Hammar wrote:

 What I was thinking of was that you could get transitive dependencies
 included which are actually also included in your super-jar. As the
 super-jar is of a different GA than the original/correct artifact, Maven
 will have no chance to handle that but you need to exclude that manually.
 In
 my experience, no normal Java developer will have a clue about this.

 The developers generally do not have to add any dependencies to their poms
 other than the libraries that we have agreed on.
 This simplifies their lives since they do not have to worry about third
 party jars.
 If there is a new library added to an individual module, the maven
 dependency hierarchy window identifies conflicts which can then be raised
 with the team to see how it should be resolved.

 Ron

  As the dependency grouping pom solves this issue I see it as a better
 Maven
 solution. However, it will make your deployment to the server involve a
 little bit more work as you need to copy more than one jar. But I assume
 you
 have tools to do this so it shouldn't be an issue, right?

 /Anders

 On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
 rwhee...@artifact-software.comwrote:

   On 25/08/2010 2:45 AM, Anders Hammar wrote:

  I don't think that I would call Ron's solution a best-practice (I see
 issues
 with transitive dependencies).

  Can you elaborate? We have not found any problems yet but perhaps we
 have
 been lucky.
 We do pay attention to version conflicts while building the aggregate
 jars.
 Are we missing something?


  If you want something as simple as just

 adding one dependency, you should create a pom project that groups these
 dependencies. Tim explains this in this blog post:


 http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

 However, be aware that there are drawbacks with this solution. For one,
 the
 mvn dependency:analyze won't work as the dependencies go one the wrong
 level. The import pom solution that Stephen suggests does not have this
 limitation, which is very nice.

 /Anders

 On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
 rwhee...@artifact-software.comwrote:

   This is a common problem in a portal environment or SOA architecture

 where
 many webapps are generated.
 We solved this by creating a set of projects that create sets of jars
 that
 group together a bunch of jars into one massive jar.

 For example, we have a spring-mysql-hibernate-tomcat project that
 creates
 an aggregated jar with all of the libraries included in this set of
 projects.
 The POM that manages this project has all the version numbers so the
 parent
 pom of all of the modules only specifies the application version and
 the
 module only depends on our set of aggregated POMs.

 If you want to change the version of a Hibernate library you only have
 to
 change it in one place.
 The POMs that create individual application artifacts do not know
 anything
 about the version of Hibernate, they only depend on the current
 ($project.version) version of the application to get all the right bits
 and
 pieces of spring, mysql, hibernate and tomcat.

 This really simplifies the management of individual portlets or web
 services.
 They call on one parent POM that specifies the {$project.version} and
 use
 this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
 CXF,
 etc.
 This means that a module's POM is very stable and only has 4 or 5
 dependencies.
 We also deploy the aggregated jars into the Tomcat shared library.

 This makes the webapps very small and reduces the number of choices
 that
 a
 developer has to make about third party jars.

 Ron




 On 24/08/2010 5:54 PM, Zac Thompson wrote:

  I've racked my brain to come up with an ideal solution to this,

 without success, so I'm throwing myself on the mercy of the group.
 Any and all advice is greatly appreciated.

 I have a project with many modules that are all released together;
 let's say they're in group ca.zac.A.  The parent pom (also the
 aggregator) for the group defines dependencyManagement for all the
 child poms so that keeping versions consistent within the group and
 releasing them together is easy.  So far, so good.

 But other projects might depend on a subset of the group, or have
 transitive dependencies on them, so I list the whole set of ca.zac.A
 modules in the dependencyManagement section of each such project: I
 want to be sure of keeping the versions consistent and known, and
 sometimes Maven's resolution ends up choosing mixed versions.  But
 adding the whole set means I end up duplicating a large block of the
 POM in multiple projects.  And if I add a new module that might get
 transitively included, 

Maven throwing error when building from Continuum

[Eric Fetzer]

I reveive the following error when attempting to build a project from continuum 
using Maven.  Not sure if this is the right mailing list as this error doesn't 
happen when building from the command line in maven:

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] An Ant BuildException has occured: 
/home/continuum/apache-continuum-1.3.6/data/working-directory/myProject-client-ria/src/main/flex/assets
 does not exist.

[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An Ant BuildException 
has occured: 
/home/continuum/apache-continuum-1.3.6/data/working-directory/myProject-client-ria/src/main/flex/assets
 does not exist.
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant 
BuildException 
has occured: 
/home/continuum/apache-continuum-1.3.6/data/working-directory/myProject-client-ria/src/main/flex/assets
 does not exist.
at 
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:224)

at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:81)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)

... 17 more
Caused by: 
/home/continuum/apache-continuum-1.3.6/data/working-directory/myProject-client-ria/src/main/flex/assets
 does not exist.
at 
org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:474)

at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:449)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at 
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:211)

... 20 more


The thing that confuses me is, why is it looking in 
data/working-directory/myProject-client-ria..., when just before this error, it 
was working in /data/working-directory/25/target/myProject-client-ria?  Seems 
it 
is in the completely wrong place.  Any help?

Thanks,
Eric


  

Maven build for compiling JavaScript project

[Jacob Beard]

Hi,

I'm working on a Commons sandbox component which is written mostly in 
JavaScript. I currently have an ant build which includes tasks to do the 
following:


1. combine all of the JavaScript modules into a single file
2. minify the combined JavaScript file using the Google Closure 
JavaScript compiler
3. compile the combined JavaScript file to a single Java class file 
using the Rhino jsc compiler

4. create an executable JAR containing the class file.

I'm interested in working toward releasing the project, and so I'm 
trying to determine what would be the most elegant way to now build this 
project with Maven. Based on my understanding of the tasks performed by 
Maven when staging a release, it seems to me that the compiler task 
would need to be made to delegate to tasks 1-3 of the project's Ant 
script. After the class file has been created with jsc, I believe the 
Maven jar and assembly tasks should work as though the project were a 
regular Java project.


If my understanding so far is correct, I'm wondering what is the best 
way to override or customize the behaviour of Maven's compiler task so 
that it delegates to Ant (probably via the antrun Maven plugin)?


I'd appreciate any guidance anyone can provide. Thanks,

Jake

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

Re: Maven build for compiling JavaScript project

[Justin Edelson]

Assuming that you want to continue to use your build.xml for 1-3, then
you just need to bind the antrun plugin's run goal to the compile phase.

Maven doesn't have tasks. It has goals and phases.

Justin

On 8/25/10 11:05 AM, Jacob Beard wrote:
 Hi,
 
 I'm working on a Commons sandbox component which is written mostly in
 JavaScript. I currently have an ant build which includes tasks to do the
 following:
 
 1. combine all of the JavaScript modules into a single file
 2. minify the combined JavaScript file using the Google Closure
 JavaScript compiler
 3. compile the combined JavaScript file to a single Java class file
 using the Rhino jsc compiler
 4. create an executable JAR containing the class file.
 
 I'm interested in working toward releasing the project, and so I'm
 trying to determine what would be the most elegant way to now build this
 project with Maven. Based on my understanding of the tasks performed by
 Maven when staging a release, it seems to me that the compiler task
 would need to be made to delegate to tasks 1-3 of the project's Ant
 script. After the class file has been created with jsc, I believe the
 Maven jar and assembly tasks should work as though the project were a
 regular Java project.
 
 If my understanding so far is correct, I'm wondering what is the best
 way to override or customize the behaviour of Maven's compiler task so
 that it delegates to Ant (probably via the antrun Maven plugin)?
 
 I'd appreciate any guidance anyone can provide. Thanks,
 
 Jake
 
 -
 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: Maven throwing error when building from Continuum

[Wendy Smoak]

On Wed, Aug 25, 2010 at 11:03 AM, Eric Fetzer elstonk...@yahoo.com wrote:
 I reveive the following error when attempting to build a project from 
 continuum
 using Maven.  Not sure if this is the right mailing list as this error doesn't
 happen when building from the command line in maven:

Please re-post your question on the Continuum users list.  You can
find subscription info at http://continuum.apache.org/mail-lists.html
.

-- 
Wendy

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

Re: Maven build for compiling JavaScript project

[Olivier Lamy]

Hi,

You must have a look at create your own packaging (ie javascript) with
a custom lifecycle.
There is a sample for something similar to your use case here :
http://svn.codehaus.org/mojo/trunk/sandbox/javascript-maven-tools/

2010/8/25 Jacob Beard jbea...@cs.mcgill.ca:
 Hi,

 I'm working on a Commons sandbox component which is written mostly in
 JavaScript. I currently have an ant build which includes tasks to do the
 following:

 1. combine all of the JavaScript modules into a single file
 2. minify the combined JavaScript file using the Google Closure JavaScript
 compiler
 3. compile the combined JavaScript file to a single Java class file using
 the Rhino jsc compiler
 4. create an executable JAR containing the class file.

 I'm interested in working toward releasing the project, and so I'm trying to
 determine what would be the most elegant way to now build this project with
 Maven. Based on my understanding of the tasks performed by Maven when
 staging a release, it seems to me that the compiler task would need to be
 made to delegate to tasks 1-3 of the project's Ant script. After the class
 file has been created with jsc, I believe the Maven jar and assembly tasks
 should work as though the project were a regular Java project.

 If my understanding so far is correct, I'm wondering what is the best way to
 override or customize the behaviour of Maven's compiler task so that it
 delegates to Ant (probably via the antrun Maven plugin)?

 I'd appreciate any guidance anyone can provide. Thanks,

 Jake

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





-- 
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

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

Re: how to best manage versions for a large common set of dependencies

[Ron Wheeler]

 On 25/08/2010 9:46 AM, Anders Hammar wrote:

As long as you know about the drawbacks. It makes me remember all those
trouble free days of ant..

classpath
   fileset dir=lib
 include name=**/*.jar/
   /fileset
/classpath

:-)


It does have a bit of that air about it from the programmers side but
1) Central control over library use does reduce the proliferation of 
versions of the same package
2) Once you declare your dependence on 
com.artifact_software.lms:lms-pom-spring-hibernate-mysql-tomcat:1.9.1 
you don't have to guess if your module has the right core setup. Got 
tired of finding spring 2.0.5 jars in webapps that were part of an 
application that was supposed to be running 2.5.6

3) Pom files are much simpler to standardize.
4) Much easier to on-board a new person. If you want to know what Apache 
packages are in use and can be used without raising a team discussion, 
just look at the lms-pom-shared.
5) When we went from Tomcat 5 to 6, I did not have to look through 40 
webapps to be sure that no one had a Tomcat 5 jar stuck somewhere.


On the downside it does make where used a bit tougher for the less 
ubiquitous libraries like Apache POI which is only used in 3 or 4 
webapps. it is in shared so all projects might be using it as far as 
Maven is concerned.




Ron



/Anders

On Wed, Aug 25, 2010 at 15:30, Ron Wheeler
rwhee...@artifact-software.comwrote:


  On 25/08/2010 9:07 AM, Anders Hammar wrote:


What I was thinking of was that you could get transitive dependencies
included which are actually also included in your super-jar. As the
super-jar is of a different GA than the original/correct artifact, Maven
will have no chance to handle that but you need to exclude that manually.
In
my experience, no normal Java developer will have a clue about this.


The developers generally do not have to add any dependencies to their poms
other than the libraries that we have agreed on.
This simplifies their lives since they do not have to worry about third
party jars.
If there is a new library added to an individual module, the maven
dependency hierarchy window identifies conflicts which can then be raised
with the team to see how it should be resolved.

Ron

  As the dependency grouping pom solves this issue I see it as a better

Maven
solution. However, it will make your deployment to the server involve a
little bit more work as you need to copy more than one jar. But I assume
you
have tools to do this so it shouldn't be an issue, right?

/Anders

On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
rwhee...@artifact-software.comwrote:

   On 25/08/2010 2:45 AM, Anders Hammar wrote:

  I don't think that I would call Ron's solution a best-practice (I see

issues
with transitive dependencies).

  Can you elaborate? We have not found any problems yet but perhaps we

have
been lucky.
We do pay attention to version conflicts while building the aggregate
jars.
Are we missing something?


  If you want something as simple as just


adding one dependency, you should create a pom project that groups these
dependencies. Tim explains this in this blog post:


http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

However, be aware that there are drawbacks with this solution. For one,
the
mvn dependency:analyze won't work as the dependencies go one the wrong
level. The import pom solution that Stephen suggests does not have this
limitation, which is very nice.

/Anders

On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
rwhee...@artifact-software.comwrote:

   This is a common problem in a portal environment or SOA architecture


where
many webapps are generated.
We solved this by creating a set of projects that create sets of jars
that
group together a bunch of jars into one massive jar.

For example, we have a spring-mysql-hibernate-tomcat project that
creates
an aggregated jar with all of the libraries included in this set of
projects.
The POM that manages this project has all the version numbers so the
parent
pom of all of the modules only specifies the application version and
the
module only depends on our set of aggregated POMs.

If you want to change the version of a Hibernate library you only have
to
change it in one place.
The POMs that create individual application artifacts do not know
anything
about the version of Hibernate, they only depend on the current
($project.version) version of the application to get all the right bits
and
pieces of spring, mysql, hibernate and tomcat.

This really simplifies the management of individual portlets or web
services.
They call on one parent POM that specifies the {$project.version} and
use
this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
CXF,
etc.
This means that a module's POM is very stable and only has 4 or 5
dependencies.
We also deploy the aggregated jars into the Tomcat shared library.

This makes the webapps very small and reduces the number of choices
that
a
developer has to make about third party jars.

Ron




On 

packaging php files in jar

[john redden]

Peer Maven users,

I have a new project where the top scheduling half is a Java app that
executes php scripts on various criteria.  I want to package the php
files in the jar along with all the usual suspects.

I can get my php files into the target directory, but can't seem to get
them automatically included in a jar file. The Java structure is as it
should be.

The pom.xml is attached

Any suggestions?   Many thanks in advance.

-John R.




pom.xml
Description: XML document

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

Re: Maven build for compiling JavaScript project

[Manos Batsis]

On 08/25/2010 06:05 PM, Jacob Beard wrote:

I'm working on a Commons sandbox component which is written mostly in
JavaScript. I currently have an ant build which includes tasks to do the
following:

1. combine all of the JavaScript modules into a single file
2. minify the combined JavaScript file using the Google Closure
JavaScript compiler
3. compile the combined JavaScript file to a single Java class file
using the Rhino jsc compiler
4. create an executable JAR containing the class file.

I'm interested in working toward releasing the project, and so I'm
trying to determine what would be the most elegant way to now build this
project with Maven. Based on my understanding of the tasks performed by
Maven when staging a release, it seems to me that the compiler task
would need to be made to delegate to tasks 1-3 of the project's Ant
script. After the class file has been created with jsc, I believe the
Maven jar and assembly tasks should work as though the project were a
regular Java project.

If my understanding so far is correct, I'm wondering what is the best
way to override or customize the behaviour of Maven's compiler task so
that it delegates to Ant (probably via the antrun Maven plugin)?



The way I get this, you don't have to change the behavior of Maven's 
compiler plugin.


If you check out [1], you'll see there are plenty of lifecycle phases to 
hook your ant tasks (or whatnot) and perform steps 1, 2 and 3.


For example, I'd probably use generate-(re)sources/process-(re)sources 
to perform 1 and 2.


For step 3, generate-sources is greate for code generation (i.e. if that 
jsc thingy produces .java code), otherwise I'd just throw in the 
generated class files in the target during prepare-package or, 
especially if you need tests, process-classes.


Step 4 will be taken care of by maven automatically using the default 
jar packaging.


Perhaps you would be interested in helping us implement 1-3 in the 
maven-jstools-plugin [2] ;-)


[1] 
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference


[2] http://dev.abiss.gr/mvn-jstools

hth,

Manos


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

Re: packaging php files in jar

[Manos Batsis]

On 08/25/2010 09:04 PM, john redden wrote:

Peer Maven users,

I have a new project where the top scheduling half is a Java app that
executes php scripts on various criteria.  I want to package the php
files in the jar along with all the usual suspects.

I can get my php files into the target directory, but can't seem to get
them automatically included in a jar file. The Java structure is as it
should be.

The pom.xml is attached



Where are your PHP files stored? I think they will automatically be 
included in the jar if stored in src/main/resources, although I'd 
probably put them in src/main/php and then


  build
...
resources
  resource
directory src/main/php/directory
includes
  include**/*.php/include
/includes
  /resource
  ...
/resources
...
  /build

For the record, I've had too much coffee.

Manos

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

Re: packaging php files in jar

[Wayne Fay]

 The pom.xml is attached

 Any suggestions?   Many thanks in advance.

Perhaps try using the build-helper-m-p specifically add-source or
add-resource mojo instead of current configuration you're doing with
m-resources-p and m-jar-p.
http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html

Wayne

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

Re: packaging php files in jar

[john redden]

Bingo!

Thanks,  I haven't had enough coffee ...

-John R.


On Wed, 2010-08-25 at 21:47 +0300, Manos Batsis wrote:
 On 08/25/2010 09:04 PM, john redden wrote:
  Peer Maven users,
 
  I have a new project where the top scheduling half is a Java app that
  executes php scripts on various criteria.  I want to package the php
  files in the jar along with all the usual suspects.
 
  I can get my php files into the target directory, but can't seem to get
  them automatically included in a jar file. The Java structure is as it
  should be.
 
  The pom.xml is attached
 
 
 Where are your PHP files stored? I think they will automatically be 
 included in the jar if stored in src/main/resources, although I'd 
 probably put them in src/main/php and then
 
build
  ...
  resources
resource
  directory src/main/php/directory
  includes
include**/*.php/include
  /includes
/resource
...
  /resources
  ...
/build
 
 For the record, I've had too much coffee.
 
 Manos
 
 -
 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: Maven build for compiling JavaScript project

[Jacob Beard]

Justin and Olivier,

Thanks for the replies. I now have a better understanding of how Maven 
works, and have been able to get this working.


Jake

On 10-08-25 11:14 AM, Olivier Lamy wrote:

Hi,

You must have a look at create your own packaging (ie javascript) with
a custom lifecycle.
There is a sample for something similar to your use case here :
http://svn.codehaus.org/mojo/trunk/sandbox/javascript-maven-tools/

2010/8/25 Jacob Beardjbea...@cs.mcgill.ca:
   

Hi,

I'm working on a Commons sandbox component which is written mostly in
JavaScript. I currently have an ant build which includes tasks to do the
following:

1. combine all of the JavaScript modules into a single file
2. minify the combined JavaScript file using the Google Closure JavaScript
compiler
3. compile the combined JavaScript file to a single Java class file using
the Rhino jsc compiler
4. create an executable JAR containing the class file.

I'm interested in working toward releasing the project, and so I'm trying to
determine what would be the most elegant way to now build this project with
Maven. Based on my understanding of the tasks performed by Maven when
staging a release, it seems to me that the compiler task would need to be
made to delegate to tasks 1-3 of the project's Ant script. After the class
file has been created with jsc, I believe the Maven jar and assembly tasks
should work as though the project were a regular Java project.

If my understanding so far is correct, I'm wondering what is the best way to
override or customize the behaviour of Maven's compiler task so that it
delegates to Ant (probably via the antrun Maven plugin)?

I'd appreciate any guidance anyone can provide. Thanks,

Jake

-
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

Use Maven Offline

[Jason Madrigal Montoya]

I'm new to maven and I want to know if it's posible to use it without an
internet conection?.
Just download plugins and install localy manually...
How to do it??


thanks.

Re: Maven build for compiling JavaScript project

[Jacob Beard]

Hi Manos,

Replies below:

On 10-08-25 02:41 PM, Manos Batsis wrote:
The way I get this, you don't have to change the behavior of Maven's 
compiler plugin.


If you check out [1], you'll see there are plenty of lifecycle phases 
to hook your ant tasks (or whatnot) and perform steps 1, 2 and 3.


For example, I'd probably use generate-(re)sources/process-(re)sources 
to perform 1 and 2.


For step 3, generate-sources is greate for code generation (i.e. if 
that jsc thingy produces .java code), otherwise I'd just throw in the 
generated class files in the target during prepare-package or, 
especially if you need tests, process-classes.
I think you might be right, the way you describe may better integrate 
with the Maven lifecycle than having tasks 1,2 and 3 all be executed 
within the compile phase. However, it's not clear to me how what you 
propose could be implemented using the Maven AntRun plugin. The reason 
for this is that, currently in the Ant script, tasks 1, 2, and 3 depend 
on one-another such that 3 depends on 2, and 2 depends on 1. This is 
desirable, as, when calling the task 3 in the Ant script without Maven, 
tasks 1 and 2 should be executed before 3. If one were to delegate to 
tasks 1, 2, and 3 at different phases in the Maven lifecycle, then 
during the Maven build process, task 1 would be executed, then task 1 
followed by task 2, then task 1 followed by 2 followed by 3. It seems 
like to change this behaviour would involve removing the dependencies in 
the Ant script, which I feel would essentially be breaking the script.


If I've misunderstood something, or there's a better way to implement 
this, please let me know.


Perhaps you would be interested in helping us implement 1-3 in the 
maven-jstools-plugin [2] ;-)

Sure. If you don't mind an Ant dependency, then the work is already done:

https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/scxml-js/trunk/build.xml

If you have a native Maven plugin in mind, that would be something I 
could perhaps assist with in the future as well.


Thanks,

Jake

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

Re: Use Maven Offline

[Wayne Fay]

 I'm new to maven and I want to know if it's posible to use it without an
 internet conection?.
 Just download plugins and install localy manually...

Yes but it can be a hassle. Realistically you should install a Maven
Repo Manager (Nexus, Artifactory, etc) and install/deploy files to it,
then point your Maven clients to it as a proxy/mirror etc.

Wayne

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

Re: Correcting a groupID

[sebb]

On 25 August 2010 03:47, Wayne Fay wayne...@gmail.com wrote:
 If a project uses the old groupId to download the release with the new
 groupId then it will find the relocation POM, and Maven can
 potentially correlate the old and new groupIds. However if the project
 uses the new groupId, the relocation POM will not necessarily be read.

 Realistically, people should simply expect that they will need to be a
 little bit hands-on with their pom files and dependencies -- even the
 transitive ones. Using Maven should not be viewed as entirely free
 -- you will occasionally need to get your hands dirty and actually
 look at the dependency graph for your artifacts.

 You can use dependency exclusions to eliminate unwanted artifacts
 under the old groupId without much trouble. You can also encourage
 your own dependencies (direct and transitive) to update to the new
 groupId the next time they push a new release etc.

Unfortunately that is not feasible in general.

 It should also be made very clear that choosing the groupId (etc.)
 needs to be done very carefully, as it is difficult to change later

 Its not so much difficult (for you) to change as it is a pain for your
 users (assuming you're a library) since they will need to use
 dependency exclusions etc.

Exactly - Commons is keen to minimise causing pain for users.

Imagine the work that would be required if Commons Logging or Lang
changed groupId.

In the case of Commons Net there are probably fewer dependencies, but
it is still a low-level library.

 Wayne

 -
 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: Correcting a groupID

[Benson Margulies]

Let me recap the pain scenario here:

Existing poms reference commons-net under the old group ID.

commons-net releases a new version under a new group ID.

Dependencies under the old group ID won't be seen as 'the same thing'
as the new group ID, so

a project that references the new group ID and has a dependency that
uses the old group ID gets both in the classpath, and probably
experiences chaos until repaired with exclusions.

Unless maven grew a feature whereby the new artifact could explicitly
declare itself a successor of the old one under the other name, this
is unavoidable. Either don't rename or live with this as an annoyance
to the users of the new version. Renaming packages might help, insofar
as the two versions might then coexist happily.

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

Which dependency scope is most appropriate for dependencies of the build script itself?

[Jacob Beard]

Hi,

I've just read the Introduction to the Dependency Mechanism document: 
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html


My project still relies heavily on Ant for building, but I'm migrating 
to Maven for dependency management, among other things.


There are several libraries that are used in my project's Ant build 
script, but not in the application itself. Examples of these include 
ant-contrib, bean scripting framework, and commons-logging. I'm 
wondering, what Maven dependency scope is most appropriate for these 
kinds of dependencies? It seems tricky, because these dependencies are 
required for neither compilation nor execution of the project's source 
code, but are instead required for executing the build script.


Let me know what you think. Thanks,

Jake

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

Re: Which dependency scope is most appropriate for dependencies of the build script itself?

[Justin Edelson]

Shouldn't these just be dependencies of the antrun plugin instead of
your project?

On 8/25/10 7:23 PM, Jacob Beard wrote:
 Hi,
 
 I've just read the Introduction to the Dependency Mechanism document:
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
 
 
 My project still relies heavily on Ant for building, but I'm migrating
 to Maven for dependency management, among other things.
 
 There are several libraries that are used in my project's Ant build
 script, but not in the application itself. Examples of these include
 ant-contrib, bean scripting framework, and commons-logging. I'm
 wondering, what Maven dependency scope is most appropriate for these
 kinds of dependencies? It seems tricky, because these dependencies are
 required for neither compilation nor execution of the project's source
 code, but are instead required for executing the build script.
 
 Let me know what you think. Thanks,
 
 Jake
 
 -
 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: Which dependency scope is most appropriate for dependencies of the build script itself?

[Jacob Beard]

Hi,

Thanks for the reply.

I'm brand new to Maven, and so I don't quite understand what you mean. 
Are you saying that the antrun plugin itself should include these 
libraries as dependencies; or is it possible, in my project, to inject 
new dependencies for specific plugins, beyond what they specify on their 
own?


Please let me know. Thanks,

Jake

On 10-08-25 08:01 PM, Justin Edelson wrote:

Shouldn't these just be dependencies of the antrun plugin instead of
your project?

On 8/25/10 7:23 PM, Jacob Beard wrote:
   

Hi,

I've just read the Introduction to the Dependency Mechanism document:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html


My project still relies heavily on Ant for building, but I'm migrating
to Maven for dependency management, among other things.

There are several libraries that are used in my project's Ant build
script, but not in the application itself. Examples of these include
ant-contrib, bean scripting framework, and commons-logging. I'm
wondering, what Maven dependency scope is most appropriate for these
kinds of dependencies? It seems tricky, because these dependencies are
required for neither compilation nor execution of the project's source
code, but are instead required for executing the build script.

Let me know what you think. Thanks,

Jake

-
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: Which dependency scope is most appropriate for dependencies of the build script itself?

[Justin Edelson]

The latter. See 
http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html 
for the syntax.

On Aug 25, 2010, at 8:35 PM, Jacob Beard jbea...@cs.mcgill.ca wrote:

 Hi,
 
 Thanks for the reply.
 
 I'm brand new to Maven, and so I don't quite understand what you mean. Are 
 you saying that the antrun plugin itself should include these libraries as 
 dependencies; or is it possible, in my project, to inject new dependencies 
 for specific plugins, beyond what they specify on their own?
 
 Please let me know. Thanks,
 
 Jake
 
 On 10-08-25 08:01 PM, Justin Edelson wrote:
 Shouldn't these just be dependencies of the antrun plugin instead of
 your project?
 
 On 8/25/10 7:23 PM, Jacob Beard wrote:
   
 Hi,
 
 I've just read the Introduction to the Dependency Mechanism document:
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
 
 
 My project still relies heavily on Ant for building, but I'm migrating
 to Maven for dependency management, among other things.
 
 There are several libraries that are used in my project's Ant build
 script, but not in the application itself. Examples of these include
 ant-contrib, bean scripting framework, and commons-logging. I'm
 wondering, what Maven dependency scope is most appropriate for these
 kinds of dependencies? It seems tricky, because these dependencies are
 required for neither compilation nor execution of the project's source
 code, but are instead required for executing the build script.
 
 Let me know what you think. Thanks,
 
 Jake
 
 -
 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
 

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

Re: Which dependency scope is most appropriate for dependencies of the build script itself?

[Jacob Beard]

Great, that appears to be exactly what I was looking for.

One more question: is injecting new dependencies for specific plugins 
something that can be done in general, or only for antrun?


Jake

On 10-08-25 09:04 PM, Justin Edelson wrote:

The latter. See 
http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html 
for the syntax.

On Aug 25, 2010, at 8:35 PM, Jacob Beardjbea...@cs.mcgill.ca  wrote:

   

Hi,

Thanks for the reply.

I'm brand new to Maven, and so I don't quite understand what you mean. Are you 
saying that the antrun plugin itself should include these libraries as 
dependencies; or is it possible, in my project, to inject new dependencies for 
specific plugins, beyond what they specify on their own?

Please let me know. Thanks,

Jake

On 10-08-25 08:01 PM, Justin Edelson wrote:
 

Shouldn't these just be dependencies of the antrun plugin instead of
your project?

On 8/25/10 7:23 PM, Jacob Beard wrote:

   

Hi,

I've just read the Introduction to the Dependency Mechanism document:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html


My project still relies heavily on Ant for building, but I'm migrating
to Maven for dependency management, among other things.

There are several libraries that are used in my project's Ant build
script, but not in the application itself. Examples of these include
ant-contrib, bean scripting framework, and commons-logging. I'm
wondering, what Maven dependency scope is most appropriate for these
kinds of dependencies? It seems tricky, because these dependencies are
required for neither compilation nor execution of the project's source
code, but are instead required for executing the build script.

Let me know what you think. Thanks,

Jake

-
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

 

-
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: Which dependency scope is most appropriate for dependencies of the build script itself?

[Justin Edelson]

It is a general feature.

On Aug 25, 2010, at 10:00 PM, Jacob Beard jbea...@cs.mcgill.ca wrote:

 Great, that appears to be exactly what I was looking for.
 
 One more question: is injecting new dependencies for specific plugins 
 something that can be done in general, or only for antrun?
 
 Jake
 
 On 10-08-25 09:04 PM, Justin Edelson wrote:
 The latter. See 
 http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html
  for the syntax.
 
 On Aug 25, 2010, at 8:35 PM, Jacob Beardjbea...@cs.mcgill.ca  wrote:
 
   
 Hi,
 
 Thanks for the reply.
 
 I'm brand new to Maven, and so I don't quite understand what you mean. Are 
 you saying that the antrun plugin itself should include these libraries as 
 dependencies; or is it possible, in my project, to inject new dependencies 
 for specific plugins, beyond what they specify on their own?
 
 Please let me know. Thanks,
 
 Jake
 
 On 10-08-25 08:01 PM, Justin Edelson wrote:
 
 Shouldn't these just be dependencies of the antrun plugin instead of
 your project?
 
 On 8/25/10 7:23 PM, Jacob Beard wrote:
 
   
 Hi,
 
 I've just read the Introduction to the Dependency Mechanism document:
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
 
 
 My project still relies heavily on Ant for building, but I'm migrating
 to Maven for dependency management, among other things.
 
 There are several libraries that are used in my project's Ant build
 script, but not in the application itself. Examples of these include
 ant-contrib, bean scripting framework, and commons-logging. I'm
 wondering, what Maven dependency scope is most appropriate for these
 kinds of dependencies? It seems tricky, because these dependencies are
 required for neither compilation nor execution of the project's source
 code, but are instead required for executing the build script.
 
 Let me know what you think. Thanks,
 
 Jake
 
 -
 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
 
 
 -
 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

downloading JavaScript libraries

[Jacob Beard]

Hi,

My project includes dependencies on several JavaScript libraries, 
including Dojo, RequireJS and beautify-js. I'm currently using Ant's get 
task to download these dependencies, but I'd like to integrate this with 
my Maven build. The way I thought I would do this would be to bind an 
antrun goal to the phase in which dependencies are downloaded. However, 
after consulting the lifecycle reference 
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference, 
I cannot find a Maven phase in which dependencies are downloaded.


Please let me know if I'm on the right track, or if there is a better 
way of going about this. Thanks,


Jake

Re: downloading JavaScript libraries

[Jesse Farinacci]

Greetings,

On Wed, Aug 25, 2010 at 10:44 PM, Jacob Beard jbea...@cs.mcgill.ca wrote:
 My project includes dependencies on several JavaScript libraries, including
 Dojo, RequireJS and beautify-js. I'm currently using Ant's get task to
 download these dependencies, but I'd like to integrate this with my Maven
 build. The way I thought I would do this would be to bind an antrun goal to
 the phase in which dependencies are downloaded. However, after consulting
 the lifecycle reference
 http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference,
 I cannot find a Maven phase in which dependencies are downloaded.

Maven dependencies are downloaded in every phase, and only just before
they are required to enter that phase.

 Please let me know if I'm on the right track, or if there is a better way of
 going about this. Thanks,

I don't think you're on the right track, frankly. It would be better
for you to create a module for each of your javascript library
dependencies, and simply manually download it and put it into
src/main/script (or perhaps src/main/resources to allow the easiest
packaging). Set the version number to be whatever version of the
library you're packaging.

Then, in your projects which utilize this javascript, simply depend on
your module with the appropriate version. This would be more The Maven
Way. Good luck!

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

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

Re: Which dependency scope is most appropriate for dependencies of the build script itself?

[Anders Hammar]

If you're using Maven 2.x, be aware of MANTRUN-95 [1]. I suggest you use
latest Maven 3.0 beta and you will not have this problem.

/Anders

[1] http://jira.codehaus.org/browse/MANTRUN-95

On Thu, Aug 26, 2010 at 04:20, Justin Edelson justinedel...@gmail.comwrote:

 It is a general feature.

 On Aug 25, 2010, at 10:00 PM, Jacob Beard jbea...@cs.mcgill.ca wrote:

  Great, that appears to be exactly what I was looking for.
 
  One more question: is injecting new dependencies for specific plugins
 something that can be done in general, or only for antrun?
 
  Jake
 
  On 10-08-25 09:04 PM, Justin Edelson wrote:
  The latter. See
 http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.htmlfor
  the syntax.
 
  On Aug 25, 2010, at 8:35 PM, Jacob Beardjbea...@cs.mcgill.ca  wrote:
 
 
  Hi,
 
  Thanks for the reply.
 
  I'm brand new to Maven, and so I don't quite understand what you mean.
 Are you saying that the antrun plugin itself should include these libraries
 as dependencies; or is it possible, in my project, to inject new
 dependencies for specific plugins, beyond what they specify on their own?
 
  Please let me know. Thanks,
 
  Jake
 
  On 10-08-25 08:01 PM, Justin Edelson wrote:
 
  Shouldn't these just be dependencies of the antrun plugin instead of
  your project?
 
  On 8/25/10 7:23 PM, Jacob Beard wrote:
 
 
  Hi,
 
  I've just read the Introduction to the Dependency Mechanism document:
 
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
 
 
  My project still relies heavily on Ant for building, but I'm
 migrating
  to Maven for dependency management, among other things.
 
  There are several libraries that are used in my project's Ant build
  script, but not in the application itself. Examples of these include
  ant-contrib, bean scripting framework, and commons-logging. I'm
  wondering, what Maven dependency scope is most appropriate for these
  kinds of dependencies? It seems tricky, because these dependencies
 are
  required for neither compilation nor execution of the project's
 source
  code, but are instead required for executing the build script.
 
  Let me know what you think. Thanks,
 
  Jake
 
  -
  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
 
 
  -
  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