Re: Fw :[m2-beta-1] Ear plugin: root-context & copied JARs/WARs

[Stephane Nicoll]

On 9/20/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
> On Tue, 20 Sep 2005 [EMAIL PROTECTED] wrote:
> 
> Hi,
> 
> 
> > Nobody has an answer for these 2 little questions?

Sorry, was quite busy yesterday.

> > 1- how can I tell the Ear plugin to use a specific root-context for a War
> > when it generates the application.xml? (instead of using the artifactId)
> > Something like the "" in m1.
> 
> Use the plugin configuration. You can specify configuration options for
> the modules:
> 
>   
> 
>   /yourContextRoot/
>   the_web_uri 
> 
>   
> 
> Maybe Stephane Nicoll can confirm if this is correct?

It is except that you need of course to identify which artifact you
want to customize. There's an help page on the web site but it's not
linked properly :/

http://maven.apache.org/maven2/plugins/maven-ear-plugin/configuration-examples.html

You should find all usefull information there. We will fix the link for beta2.

> > 2- when the plugin generates the Ear, it packages most dependencies of the
> > War module, while they already exist the the WEB-INF/lib of the War (and I
> > don't want them to be copied a second time at the root of the Ear). Those
> > dependencies have a "compile" scope in the pom of the War module. Is it the
> > normal behaviour? Is there a property or something to tell m2 not to
> > package them?
> 
> Well this is a bit of a problem.
> You can specify the dependencies in the war pom with scope 'provided',
> so they won't end up in the war.
> This works great if you always use the war within an ear that also has
> those dependencies, but if you use that war standalone it'll break.
> Also, those war dependencies are not transferred to the ear project,
> so you have to respecify them there.

The link above explains the 'excluded' property you can set on an
artifact to ignore it application.xml generation. As kenny said, this
is indeed a bit of a problem. I'll think on that, do not hesitate to
ping us if you have ideas.

Cheers,
Stéphane

-- 
.::You're welcome ::.

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

Re: [m2] reasons for sticking with maven

[Wim Deblauwe]

Very good that we have this in JIRA, I could use this also. I have now 
created a custom goal for maven 1 that does this (drawback is that we don't 
have the scoped dependencies there, so that is a bit of a problem, but it 
works)

regards,

Wim

2005/9/20, Mark Hobson <[EMAIL PROTECTED]>:
> 
> Isn't this covered by http://jira.codehaus.org/browse/MNG-932 ?
> 
> Mark
> 
> On 20/09/05, John Casey <[EMAIL PROTECTED]> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Another solution might be an attached artifact (logically attached to
> > the main .jar in the repository via the metadata) that would be
> > available to other projects...so producing project A might also produce:
> >
> > a-version-tests.jar
> >
> > and you could then depend on it like such:
> >
> > 
> > ~ some.group
> > ~ a
> > ~ someVersion
> > ~ test-jar
> > ~ test
> > 
> >
> > would that solve the problem?
> >
> > - -john
> >
> > Carsten Ziegeler wrote:
> > | Dave Neuer wrote:
> > |
> > |>Yes, that's a workaround I'm not OK with, so a developer cannot be in
> > |>/masterProject/projectA and do "m2 test," see BUILD SUCCESSFUL and 
> think
> > |>that everything is OK and check in a bunch of broken code because no
> > |>tests
> > |>were run -- since the tests for A don't live in A.
> > |>
> > |
> > | Oh no, they are still in A - that's trick :) (ok, one could call it
> > | hack). You have the correct pom for A containing the tests. You make a
> > | sub directory in project A: "tests-for-b", add a pom.xml there
> > | referencing the tests of A as src (using "../") and then it works.
> > |
> > |
> > |>Again, I did write a maven-test-artfiact plugin which has a compile 
> and
> > |>install target; it *does* generate a test artifact (default name
> > |>${artifactId}-test.${packaging}, but it's configurable.
> > |>
> > |>However, it doesn't generate a POM, and even w/ a manually generated
> > |>one, and a declared dependancy on A's test artifact in project B,
> > |>surefire doesn't run the tests in the baseclasses which reside in the
> > |>test.jar.
> > |>
> > |>That's where I got, and where I ran out of patience and time to keep
> > |>going. I'd be happy to ask my manager if we can release this code if
> > |>someone else were interested in running w/ it.
> > |>
> > |
> > | It would be interesting to hear what the m2 developers say about this
> > | problem :)
> > |
> > | Carsten
> > |
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.2.6 (GNU/Linux)
> >
> > iD8DBQFDMFs1K3h2CZwO/4URAq1eAJwMu6k7TkUiR25AcmxtHAGm77U26wCfRiBh
> > uTSibc3Gno8WdJEABwrM6BM=
> > =6B7J
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: [ANN] Article on building J2EE projects with Maven 1.1

[Felipe Leme]

On 9/17/05, Vincent Massol <[EMAIL PROTECTED]> wrote:
> fine for me. You could try using:
> http://brahe.discursive.com/svn/mdn/code/j2ee (the mavenbook.org domain name

I have tried it already and it didn't work neither.

Anyway, I tried again at home and it worked - there might be some
firewall issue at work.

-- Felipe

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

[m2] How to get logging from commons-exec?

[Wendell Beckwith]

I checked out the source for commons-exec and built the
commons-exec-1.0-SNAPSHOT.jar. I added this jar as a dependency to my m2
plugin project and wrote a simple Foo app to verify that everything was
working. The app just writes the current time into a file and all is well
with this. What's missing is how to tie the output from my process into the
currently executing maven process. Below is my mojo's execute method. None
of the unit tests actually demonstrate how to configure the current process
to receive logging from a sub-process.


public void execute() throws MojoExecutionException
{
CommandLine cl = new CommandLineImpl();
cl.setExecutable("java");
cl.addArgument("-classpath");
cl.addArgument("D:/dev/workspace/maven-hello-plugin/bin");
cl.addArgument("com.mycompany.maven.plugins.Foo");
try
{
Exec exec = new Exec();
exec.execute(cl);
}
catch (IOException e)
{
throw new MojoExecutionException(e);
}
}


Wb

RE: Announcements mailing list

[Jeff Jensen]

Wonderful on the announce, thanks!

Also thanks for the historical on the unified lists.  I can very much
appreciate the reasons for the decisions.  Ironically, seeing the M2
problems simply enforces the need for my team to stay on m1 for awhile yet!
(too big a team, too much risk at this point)

It's great that users are self-motivated to prefix the subjects.  It makes a
[m2] filter work pretty well.

Thanks for the ear...


-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 20, 2005 9:52 PM
To: Maven Users List
Subject: Re: Announcements mailing list

On 9/21/05, Jeff Jensen <[EMAIL PROTECTED]> wrote:
> 
> I would very much appreciate some type of announce list


I've put the request in. 


Another user mailing list issue is the overloading of both m1 and m2 on the
> same list. 


Some time back, we voted to unify. This was more on the dev side, but I 
think its good that users mirrors that. Basically, we want to avoid 
fragmenting the community into 2 separate groups - and a lot of issues (such

as general practices) affect both communities and we wouldn't want one or 
the other to miss it. Also, it's great to let the m1 users know what they 
are missing :D

Happy to rediscuss this, but maybe some filtering (people seem to have 
adopted a convention of [m1 or [m2 ...) might help?

Cheers,
Brett


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

Re: [m2] finalName in install and version for different environments

[Brett Porter]

This is a bug we are hoping to fix shortly. While finalName can't be 
completely modified for installing in the repository, it should be possible 
to add a classifier for the environment. For reference, the JIRA bug is the 
one referring to attaching an artifact with a classifier via a profile.

- Brett

On 9/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> I have a project to build / deploy for three different enviroments
> (test,integration, production with different configs) and want to set the
> jar file name depending on the active profile.
> 
> I know one possibility is with the finalName Element. The jar process uses
> the finalName and generate the jar with the correct name (specified by
> finalName)
> But the install process doesn't use the finalName.
> 
> How can I achieve it that the install process (and of course the deploy
> process) also uses the finalName.
> 
> Please help!
> 
> TIA
> 
> Martin Kuhn
> 
> 
> 
> 
> 
> ++
> Diese Nachricht ist vertraulich und ausschließlich für den/die Adressaten
> bestimmt. Sollten Sie nicht der beabsichtigte Adressat, einer seiner
> Mitarbeiter oder sein Empfangsbevollmächtigter sein, ist jede Form der
> Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des
> Inhalts dieser Nachricht unzulässig. In diesem Fall bitten wir, den
> Absender umgehend zu benachrichtigen und die Nachricht zu vernichten.
> Elektronisch versandte Nachrichten können durch Unberechtigte manipuliert
> und/oder gelesen werden, weshalb jegliche Haftung hierfür ausgeschlossen
> wird.
> ++
> This communication is confidential and is intended solely for the
> addressee(s). If you are not the intended recipient(s), his/her assistant,
> or authorized recipient, any form of disclosure, reproduction,
> distribution or any use of this communication or the information in it, is
> strictly prohibited and may be unlawful. In this case, please notify the
> sender immediately and destroy the e-mail. Electronic communication via
> the Internet by e-mail may be manipulated and/or read by third parties,
> thus we exclude any liability whatsoever for this e-mail.
> ++
>

Re: [m2-b1] POM Inheritance and Variables

[Brett Porter]

Of course, it is highly preferred to use profiles for this (esp. if you are 
setting the values based on the executing JDK).

Cheers,
Brett

On 9/21/05, David Pick <[EMAIL PROTECTED]> wrote:
> 
> John,
> 
> Many Thanks, that did the trick.
> 
> Cheers
> Dave
> 
> -Original Message-
> From: John Casey [mailto:[EMAIL PROTECTED]
> Sent: 20 September 2005 16:22
> To: Maven Users List
> Subject: Re: [m2-b1] POM Inheritance and Variables
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> System vars are accessed implicitly in m2...try:
> 
> 
> ~ ${build.debug}
> ~ ${build.jdk}
> ~ ${build.jdk}
> 
> 
> Cheers,
> 
> john
> 
> David Pick wrote:
> | Hi,
> |
> | I have the following section in a parent POM:
> |
> | 
> | 
> | 
> | org.apache.maven.plugins
> | maven-compiler-plugin
> | 
> | ${systemScope.getProperty('build.debug')}
> | ${systemScope.getProperty('build.jdk')}
> | ${systemScope.getProperty('build.jdk')}
> | 
> | 
> | 
> | 
> |
> |
> | When I run a Maven build on the child POM the system scope variables
> appear to have no effect.
> | If I replace them with fixed values then everything works.
> |
> | The system variables are set when invoking Maven using -D option.
> |
> | What have I done wrong?
> |
> | Does the fact that this inherited have any bearing on the property
> evaluation?
> |
> | Many Thanks
> | Dave
> |
> | -
> | To unsubscribe, e-mail: [EMAIL PROTECTED]
> | For additional commands, e-mail: [EMAIL PROTECTED]
> |
> |
> |
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQFDMCksK3h2CZwO/4URAnjtAKCR9xO/PWerEM72jUXyapJpax04KQCfQfzR
> dpkEVBR7Dwp/SaWGrB55M4w=
> =L4D+
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Announcements mailing list

[Brett Porter]

On 9/21/05, Jeff Jensen <[EMAIL PROTECTED]> wrote:
> 
> I would very much appreciate some type of announce list 


I've put the request in. 


Another user mailing list issue is the overloading of both m1 and m2 on the
> same list. 


Some time back, we voted to unify. This was more on the dev side, but I 
think its good that users mirrors that. Basically, we want to avoid 
fragmenting the community into 2 separate groups - and a lot of issues (such 
as general practices) affect both communities and we wouldn't want one or 
the other to miss it. Also, it's great to let the m1 users know what they 
are missing :D

Happy to rediscuss this, but maybe some filtering (people seem to have 
adopted a convention of [m1 or [m2 ...) might help?

Cheers,
Brett

RE: Announcements mailing list

[Jeff Jensen]

I would very much appreciate some type of announce list (and many products
with busy lists like Maven's have one!).  The user list traffic has been
increasing for awhile, and I expect it to only continue increasing!  While I
did not know the use of the Apache announce list, I really don't want the
other baggage coming with it (yes, it is low volume); I want Maven only
info.  (and yes, I did just go subscribe to it... :-).  I imagine over time
Maven having its own list would be more beneficial with the increasing
number of plugins.

Another user mailing list issue is the overloading of both m1 and m2 on the
same list.  I would very much like two separate lists.  I realize the
argument one can make of the value of both versions, but if I want info I
both versions, I could subscribe accordingly.  Both m1 and m2 will be in use
for a long time yet!

I find that both of these issues make it more difficult to deal with the
Maven information I need.  That is a lot of daily emails, and combined with
the many other product lists I am on (and I am sure others can relate!), the
situation isn't helped with these two "little" issues!

I also think the mailing list issues are just normal product growing pains,
and Maven usage is definitely growing (yea!)!  :-)


-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 20, 2005 5:13 PM
To: Maven Users List
Subject: Re: Announcements mailing list

Do we want to create/use [EMAIL PROTECTED] in addition? Perhaps to
put up plugin releases?

Or maybe [EMAIL PROTECTED] since it already exists with its 5 or so
subscribers and 1 post :)

- Brett

On 9/21/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
> 
> On Tue, 2005-09-20 at 10:52 -0700, Richard Wallace wrote:
> > Jason van Zyl wrote:
> > > We use the announce@apache.org for this. It's relatively low 
> > > traffic, but we probably won't create an announcement list 
> > > specifically for
> Maven
> > > itself.
> > >
> > Ah I see. Didn't know that. Should probably be mentioned on the 
> > mailing lists page for people like me. Guess I'll go subscribe to 
> > that
> one.
> 
> Done, thanks.
> 
> --
> Trygve
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>


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

Re: .cvspass file not found on windows.

[Eric Giguere]

Try running: changelog:create-cvspass

Hope it helps
Eric.

Mick Knutson wrote:

I am trying to setup scm in maven, and I am using wincvs to access my 
cvs server. I have searched, and do not find a .cvspass file and maven 
is also complaining about this.


How do I fix this issue? Create a .cvspas file? How with WinCvs?

Thank You
Mick Knutson

Sr. Java/J2EE Consultant
BASE logic, inc.
(415) 648-1804 (S.F., CA)
http://www.BASELogic.com

HP Consulting Services (Walnut Creek, CA)



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





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

Re: .cvspass file not found on windows.

[Jesse McConnell]

the .cvspass file ought to be created when you do a cvs login

there are a host of issues that can crop up with this on a windows box 
though..least of which is where the file is created..

I would make sure that you set a HOME environment variable and make sure you 
see it set in the shell that you run the cvs login from...then the .cvspass 
file will be generated in that directory.

the cvs documentation shows a number of the pitfalls that can crop up with 
this process.

a general rule of thumb is that if you can execute the cvs commands in a cmd 
prompt without authentication issues when maven-scm and continuum things 
shouldn't have a problem.

jesse

On 9/20/05, Mick Knutson <[EMAIL PROTECTED]> wrote:
> 
> I am trying to setup scm in maven, and I am using wincvs to access my cvs
> server. I have searched, and do not find a .cvspass file and maven is also
> complaining about this.
> 
> How do I fix this issue? Create a .cvspas file? How with WinCvs?
> 
> Thank You
> Mick Knutson
> 
> Sr. Java/J2EE Consultant
> BASE logic, inc.
> (415) 648-1804 (S.F., CA)
> http://www.BASELogic.com
> 
> HP Consulting Services (Walnut Creek, CA)
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
jesse mcconnell

Re: [m2] assembly plugin

[Johnny R. Ruiz]

Ashley Williams wrote:

Does anyone know how to use assembly:assembly, in particular what the  
descriptor is supposed to be? I did hardcode it as a path to my pom  
from within my pom (that seems wrong) which made the plugin run  
without errors, but I didn't see any output file.


Thanks
-AW

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


Ashley,

You could create your own Descriptor file.   Here is the example of 
descriptor that was used when  you run "m2 assembly:assembly 
-DdescriptorId=jar-with-dependencies".



 jar-with-dependencies
 
   jar
 
 false
 
   
 target/classes
 /
   
 
 
   
 /
 true
 runtime
   
 


You could create your own descriptor to get what you want.  To use your 
customized descriptor file, use "m2 assembly:assembly 
-Ddescriptor=path/to/your/descriptor.xml".


Hope this helps,
--- Johnny :)

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

Re: [m2] reasons for sticking with maven

[Brett Porter]

Ugh, what a long thread to wake up to when you've got a headache :)

I think there have been some very good answers here already, but I'll add my 
own thoughts for completeness.

On 9/20/05, Ashley Williams <[EMAIL PROTECTED]> wrote:
> 
> Sincere apologies to the dev team if this email seems like a troll, I
> absolutely don't mean it to be. I'm aware that they continue to do
> outstanding work and are few in number.


Thanks, much appreciated. Constructive criticism is always welcome :) 

1. Usability from Ant - there are hundreds of Ant targets out there
> that are useful for me today. I can't justify waiting for them to be
> rewritten as Maven equivalents not only because I need functionality
> today, but also because I don't see why I have to abandon my
> experience with ant.



So far we've only addressed usability OF Ant. You can run ant scripts at 
phases of the lifecycle using antrun, you can write java plugins that use 
the Ant API, and Chris and John are putting together Ant plugins. You can 
already sort of do this with Marmalade (at least that was the intent).

The key is that you still get the reusable infrastructure that Maven 
provides which is what we view as the most important feature of Maven (yes, 
its not dependency management!)

Funnily enough, before I logged in this morning, I was pondering starting 
the long overdue discussion with the Ant team on how we can best work 
together to move forward. Ant and Maven are completely different 
applications, but they could share a lot of code at the task/plugin level. 
As Jason said, we've been working to do this in the form of common libraries 
as they are also usable outside of both Ant and Maven, and it'd be good to 
get a shared direction happening there.

Using Maven from Ant? I'm not sure if that is what you meant, but that would 
be possible too and there is an open JIRA. So far, just dependency 
management is available.

2. Usability from Eclipse - when will I be able to ditch the command
> line and create and manage projects entirely from eclipse


I'm really surprised this is #2, but as others have pointed out its high on 
our list too. But we need to finish Maven first, then work on integration. 

3. Need to do a myriad of simple things such as automatically run
> java command or deploy to tomcat. I used to do this all the time in
> my ant scripts, ie run my build.xml script and at the end it would
> run my app on completion. It's a credit to those on this list who
> reply with ideas and workarounds - however this is kind of related to
> 2 above, where there are lots of ant tasks out there that are tested
> to death and that I should be able to use today.


Are you sure they are tested to death? :)

But as stated in 1), you should be able to do this just fine. The important 
thing is that you are encouraged to spend the small amount of time making it 
reusable for other projects of your own, and hopefully if something 
comprehensive is put together then it is shared with all Maven users. 

4. Online documentation. Simple example was trying to get the
> assembly plugin to work which Daniel Shomer had to look into the
> source code to advise me of what to do. This is just one example of
> many.


Yep, we're working on it. I don't think the emphasis should be on javadocs 
(With the exception of the plugins, where that is what generates the plugin 
reference). Short howtos are the approach we are taking for the Maven doco 
itself. Contributions are welcome, there is a wanted list on the web site. 

5. Other project structures. Sometimes I will encounter a project
> where all the source code is in one tree (beginning with com/). I'm
> not saying its any better than one directory per artifact, but I am
> saying I encounter such projects in my career and as such I know I
> wouldn't be able to use maven.


Oh well, its not a silver bullet. There are probably a lot of other things 
you can't do with that structured project, and maybe you don't need to. If 
at some point the benefits of restructuring and using Maven outweigh the 
costs, then go for it - in the mean time, use whatever is already there.

There's no way this would make it to #5 on my wish list :)

6. Contribute to the code. I have tried to get a foot in the door in
> order to fix some of my own critisisms, but the lack of javadocs mean
> that I really can't do this other than for some simple plugins. That
> is unless I had lots of time to spare which I don't. In turn that
> makes me concerned how the project will attract other developers to
> move things along quickly.


Yes, we're working on that too. We've had several new contributors, but 
there are some barriers to entry. Specific pointers to things that are too 
hard are good. 

Now I'll turn my attention to Ivy. I've began to look at this product
> and it seems to offer many of the features of Maven including
> 
> 1. transitive dependencies


many != 1 :)

As Jason said, apples and oranges. Ivy is a very good dependency man

Re: [m2] Extending Eclipse plugin

[Rinku]

Hi Kenney,

My comments inline...

Kenney Westerhof wrote:


On Tue, 20 Sep 2005, Rinku wrote:

 


Hi,

I have a use case where I need to reuse/extend the functionality
provided by existing M2 Eclipse plugin. The use case involves creating
"deployables" directory from defined project properties and some other
updates to ".wtpmodules" contents.

What I want to do is to create sort of a wrapper plugin that can
delegate 'standard' goals to the Eclipse plugin and do some pre/post
processing around these 'standard' goals. Could anyone please explain
what would be a neat way to achieve this and keep the option of being
able to reuse future Eclipse plugin releases but just updating the
version numbers in pom.
   



I think it would be better if your changes are put in the eclipse plugin
(at least for the contents of the .wtpmodules). Creation of custom
directories on the other hand is not something the eclipse plugin should
do - the maven build should create those too as it needs it.. maybe just
use a target/... directory for that and let eclipse automatically create
it, like target/classes?
 

Yes, I thought about putting my changes into the existing plugin but 
then I can't simply reuse any future versions of the Eclipse plugin. 
Agreed that creation of custom directories is not something that Eclipse 
plugin should do by default, hence motivation behind creation of wrapper 
plugin that can handle my project specific properties and delegate them 
to Eclipse plugin to get the common/standard stuff done.



What are the exact changes? Do you think they are general enough
to be added to the eclipse plugin?

 


For instance, I need to be able to:
a) create additional  definitions such that I can overlay 
resource patches for my development environment as per project properties.
b) setup  definitions and a context path from my project 
properties for my application server for use from within Eclipse IDE.


I'd prefer to use Eclipse plugin to get the work done to the extent 
possible and handle only bits that are driven by custom project properties.


Appreciate any thoughts, suggestions. 


Cheers,

Rahul .

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

.cvspass file not found on windows.

[Mick Knutson]

I am trying to setup scm in maven, and I am using wincvs to access my cvs 
server. I have searched, and do not find a .cvspass file and maven is also 
complaining about this.


How do I fix this issue? Create a .cvspas file? How with WinCvs?

Thank You
Mick Knutson

Sr. Java/J2EE Consultant
BASE logic, inc.
(415) 648-1804 (S.F., CA)
http://www.BASELogic.com

HP Consulting Services (Walnut Creek, CA)



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

RE: Working with Branches

[Jay H. Hartley]

In Maven 1 properties:

maven.scm.tag=BRANCH_TAG_NAME
See:
http://maven.apache.org/reference/plugins/scm/properties.html

In Maven 2 POM:


...
BRANCH_TAG_NAME
...

See:
http://maven.apache.org/maven2/maven-model/maven.html#class_Scm

I haven't used Maven 2 myself yet, but that's what the docs say.

Jay

-Original Message-
From: Jon Strayer [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 20, 2005 2:32 PM
To: Maven Users List
Subject: Working with Branches

Today, for the first time ever, I needed to branch a project in CVS. How do
I access that branch with Maven?


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

Re: [m2] faulty scp protocol handling in wagon?

[Brett Porter]

I have experienced this too - there is an open bug I believe. I'm not sure 
if the problem is in jsch, or our use of jsch though. I'd welcome any 
assistance you can provide.

Thanks,
Brett

On 9/21/05, Orjan Austvold <[EMAIL PROTECTED]> wrote:
> 
> Often when downloading new artifacts from a scp repository the build
> fails with
> 
> Root error:
> session is down
> 
> It could be that my the ssh configuration on the scp repository is
> faulty, but I thought I'd check here before digging into ssh-debugging.
> 
> In my pom.xml I have configured
> 
> 
> 
> secure-repository
> scp:/myhost.com/var/mavenrep/maven2
> default
> daily
> 
> 
> central
> http://ibiblio.org/maven2
> 
> 
> 
> In my settings.xml I have configured
> 
> 
> 
> 
> secure-repository
> me
> /home/me/.ssh/id_dsa
> myPassPhrase
> 
> 
> 
> 
> 
> closer-central
> http://mirrors.sunsite.dk/maven2
> default
> daily
> central
> 
> 
> 
> 
> 
> Best regards,
> Ørjan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: [m2] site:deploy password

[Brett Porter]

Please file a JIRA request for the command line entry, that should be 
possible now. Mostly we use private keys without a passphrase for this at 
the moment.

I'm not aware of why it might be hanging. Can you scp the file to the remote 
server outside of Maven? Does the ssh server logs show anything of 
assistance?

- Brett

On 9/21/05, Ashley Williams <[EMAIL PROTECTED]> wrote:
> 
> Is there some way of specifying the ssh password from the command
> line as I really don't want to embed it in my settings.xml file. I
> would much rather enter it every time - I'm referring to this section:
> 
> 
> tomcat
> ashley
> 
> 
> 
> Additionally does anyone know why site:deploy might hang? It's been
> sitting there for five minutes now with this output:
> 
> [INFO] [site:deploy]
> Executing command: mkdir -p /Applications/tomcat/webapps/projects/
> master/essential
> Executing command: mkdir -p /Applications/tomcat/webapps/projects/
> master/essential/
> 
> Executing command: scp -t /Applications/tomcat/webapps/projects/
> master/essential/site22199.zip
> 
> 
> Presumably I provided all the credentials successfully or the mkdir
> commands wouldn't have executed properly.
> 
> Thanks
> -AW
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Announcements mailing list

[Brett Porter]

Do we want to create/use [EMAIL PROTECTED] in addition? Perhaps to 
put up plugin releases?

Or maybe [EMAIL PROTECTED] since it already exists with its 5 or so 
subscribers and 1 post :)

- Brett

On 9/21/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
> 
> On Tue, 2005-09-20 at 10:52 -0700, Richard Wallace wrote:
> > Jason van Zyl wrote:
> > > We use the announce@apache.org for this. It's relatively low traffic,
> > > but we probably won't create an announcement list specifically for 
> Maven
> > > itself.
> > >
> > Ah I see. Didn't know that. Should probably be mentioned on the
> > mailing lists page for people like me. Guess I'll go subscribe to that 
> one.
> 
> Done, thanks.
> 
> --
> Trygve
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Working with Branches

[Jon Strayer]

Today, for the first time ever, I needed to branch a project in CVS. How do 
I access that branch with Maven?

Re: [m2] reasons for sticking with maven

[Chris Berry]

Yes, it is the equivalent. But one thing confuses me, it's not about
executing a java process (per se) -- it's about executing Ant. And
it's not about maintenance. I  think the heart of the discussion is
reuse. Not reinventing what Ant already does. Providing a mechanism
for reuse and versioning of Ant scripts. Reusing Ant scripts (or
pieces of them) from existing builds, when converting to Maven.

To the plugin developer, they can simply build an Ant script as they
always do, and a simple Mojo that passes parameters (and defaults)
from the POM in to the Ant script and executes it. Obviously, I could
have done it all within the Mojo myself, or I could have called Ant
programmatically, or I could just script the Ant. There are many ways
to get there.

To the plugin user, they don't know which technique is in use, and
shouldn't care...

On 9/20/05, Wendell Beckwith <[EMAIL PROTECTED]> wrote:
> Just for clarification are you suggesting that a plugin that needs to
> execute a java process should be designed as an ant script, and the plugin
> would simply pass parameters to the ant script? I ask because I don't see
> how this is less maintenance than my current plugin that provides
> intelligent defaults in the mojo and just needs to pass theses parameters
> along with any the user changed to the java process. Whenever there are
> plugin changes, I still go to the mojo in my design or an ant script in your
> design, correct?
>
> Wb
>
>
> On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > I've actually done something just like this in the past, in order to
> > call a Make-based build. IMO, you want to wrap a command line call in a
> > plugin, to formalize the parameters - required and optional - which
> > constitutes a valid invocation of that executable. Otherwise, it's prone
> > to breaking, misuse, and cut-and-paste maintenance style. In short, it
> > isn't robust, and doesn't scale well. Anything where execution logic is
> > embedded in the POM will suffer from this, IMO - including the antrun
> > and execute plugins in the mojos project. A better solution for Ant
> > would be to build the plugin around the Ant script/scriptlet, and bundle
> > that script into the plugin jar...then parameterize the input
> > configuration. Then, the script can climb the maturity curve, and is
> > truly reused with a single point of maintenance.
> >
> > - -john
> >
> > Vincent Massol wrote:
> > |
> > |>-Original Message-
> > |>From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
> > |>Sent: mardi 20 septembre 2005 19:15
> > |>To: Maven Users List
> > |>Subject: Re: [m2] reasons for sticking with maven
> > |>
> > |>John is basically stating the very thing that I'm against in the
> > statement
> > |>below. I have a 3rd party command line utility from
> > |>www.agitar.com ,
> > |>that basically does unit tests against our code. I want to write (and
> > have
> > |>started writing) an M2 plugin to execute the java command line for the
> > |>agitation process from my plugin. All I need now to complete my plugin
> > |>besides more hours in a day is a plugin that will allow me to execute a
> > |>java
> > |>command line. Now my plugin will integrate with the maven lifecycle
> > during
> > |>the test phase. However, first I'm told to use the maven-execute-plugin
> > |>and
> > |>then another dev states that it's bad and wants to see it eliminated,
> > I'm
> > |>left thinking WTF!? This *helps* me adopt maven and the process, not
> > |>hinders
> > |>it. My whole purpose for writing the plugin was so that I could make the
> > |>plugin once and the other groups here and else where since I would open
> > |>source it would be able to reuse it. Is this not what maven is for?
> > |
> > |
> > | Just to muddy the waters: why don't you use commons-exec from your
> > plugin's
> > | java code to execute your process?
> > |
> > | [snip]
> > |
> > | Thanks
> > | -Vincent
> > |
> > |
> > | -
> > | To unsubscribe, e-mail: [EMAIL PROTECTED]
> > | For additional commands, e-mail: [EMAIL PROTECTED]
> > |
> > |
> > |
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.2.6 (GNU/Linux)
> >
> > iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
> > 3JIbhwsALTmuwn5OB/7gG9k=
> > =WOfH
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>

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

[m2] faulty scp protocol handling in wagon?

[Orjan Austvold]

Often when downloading new artifacts from a scp repository the build 
fails with


Root error:
  session is down

It could be that my the ssh configuration on the scp repository is 
faulty, but I thought I'd check here before digging into ssh-debugging.


In my pom.xml I have configured



secure-repository
scp:/myhost.com/var/mavenrep/maven2
default
daily


central
http://ibiblio.org/maven2



In my settings.xml I have configured




secure-repository
me
/home/me/.ssh/id_dsa
myPassPhrase





closer-central
http://mirrors.sunsite.dk/maven2
default
daily
central





Best regards,
Ørjan

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

[m2] site:deploy password

[Ashley Williams]

Is there some way of specifying the ssh password from the command  
line as I really don't want to embed it in my settings.xml file. I  
would much rather enter it every time - I'm referring to this section:



  tomcat
  ashley
  


Additionally does anyone know why site:deploy might hang? It's been  
sitting there for five minutes now with this output:


[INFO] [site:deploy]
Executing command:  mkdir -p /Applications/tomcat/webapps/projects/ 
master/essential
Executing command: mkdir -p /Applications/tomcat/webapps/projects/ 
master/essential/


Executing command: scp -t /Applications/tomcat/webapps/projects/ 
master/essential/site22199.zip



Presumably I provided all the credentials successfully or the mkdir  
commands wouldn't have executed properly.


Thanks
-AW

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

Re: [m2] assembly plugin + a few instructions

[Ashley Williams]

Ok, the name of the file may suggest that it would achieve my goals,  
but in practice it doesn't.
I did give it a go and it resulted in all my jar dependencies being  
unpacked -

definitely not what I want.

Looking at the xml the line which does this is:
  true

Additionally it causes a jar file to be generated whereas I want  
something like a tar. None of

the three assembly files suit me which is why I had to tailor my own

Thanks
AW

On 20 Sep 2005, at 20:21, Daniel Schömer wrote:


Ashley Williams wrote:


I was expecting the jars from my dependencies section to be there.
[...]
Which resulted in a compressed file(s) containing my jar file and its
dependencies.
I was then able to uncompress it and launch with the java -jar  
command.




Well, you should have tried the descriptorId
"jar-with-dependencies".  It seems to me that this would have
created a jar that should fit your needs.

Daniel Schömer


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





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

Re: [m2] assembly plugin + a few instructions

[Daniel Schömer]

Ashley Williams wrote:
> I was expecting the jars from my dependencies section to be there.
> [...]
> Which resulted in a compressed file(s) containing my jar file and its  
> dependencies.
> I was then able to uncompress it and launch with the java -jar command.

Well, you should have tried the descriptorId
"jar-with-dependencies".  It seems to me that this would have
created a jar that should fit your needs.

Daniel Schömer


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

RE: [m2] reasons for sticking with maven

[Dave Neuer]

"Created: Today 08:00 AM".

That is exactly what I'm talking about.

I would have been happy to ask about donating my code, but it's unclear
to me from the referenced JIRA entry whether they're talking about
making the regular compile and install plugins do the test artifact
generation (plus making sure that surefire can run the tests -- as I
said, it didn't seem to be able to run tests from a base class in a
separate jar).

Personally, I think that this would be a common enough feature that it
really belongs in the compile and install plugins, rather than a
standalone plugin like the one I developed.

e.g.
my.project
main-artifact
main-test-artifact

and then depend on it in the manner John specified.

Dave   

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 20, 2005 3:02 PM
To: Maven Users List
Subject: Re: [m2] reasons for sticking with maven

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

yeah, that looks like it. I wasn't aware of that issue...too new, I
guess :)

Thanks, Mark.

john

Mark Hobson wrote:
| Isn't this covered by http://jira.codehaus.org/browse/MNG-932 ?
|
| Mark
|
| On 20/09/05, John Casey <[EMAIL PROTECTED]> wrote:
|
| Another solution might be an attached artifact (logically attached to
| the main .jar in the repository via the metadata) that would be
| available to other projects...so producing project A might also
produce:
|
| a-version-tests.jar
|
| and you could then depend on it like such:
|
| 
| ~  some.group
| ~  a
| ~  someVersion
| ~  test-jar
| ~  test
| 
|
| would that solve the problem?
|
| -john
|
| Carsten Ziegeler wrote:
| | Dave Neuer wrote:
| |
| |>Yes, that's a workaround I'm not OK with, so a developer cannot be
in
| |>/masterProject/projectA and do "m2 test," see BUILD SUCCESSFUL and
think
| |>that everything is OK and check in a bunch of broken code because no
| |>tests
| |>were run -- since the tests for A don't live in A.
| |>
| |
| | Oh no, they are still in A - that's trick :) (ok, one could call it
| | hack). You have the correct pom for A containing the tests. You make
a
| | sub directory in project A: "tests-for-b", add a pom.xml there
| | referencing the tests of A as src (using "../") and then it works.
| |
| |
| |>Again, I did write a maven-test-artfiact plugin which has a compile
and
| |>install target; it *does* generate a test artifact (default name
| |>${artifactId}-test.${packaging}, but it's configurable.
| |>
| |>However, it doesn't generate a POM, and even w/ a manually generated
| |>one, and a declared dependancy on A's test artifact in project B,
| |>surefire doesn't run the tests in the baseclasses which reside in
the
| |>test.jar.
| |>
| |>That's where I got, and where I ran out of patience and time to keep
| |>going. I'd be happy to ask my manager if we can release this code if
| |>someone else were interested in running w/ it.
| |>
| |
| | It would be interesting to hear what the m2 developers say about
this
| | problem :)
| |
| | Carsten
| |

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




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



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMFyrK3h2CZwO/4URAmdkAJ9EtnA8+4q/E1y9vFW/qCzlrPueRgCeJ2Ho
OImXL7E2wJ3HxevjML4egXg=
=F56A
-END PGP SIGNATURE-

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


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

Re: [m2] reasons for sticking with maven

[Mark Hobson]

On 20/09/05, John Casey <[EMAIL PROTECTED]> wrote:
> yeah, that looks like it. I wasn't aware of that issue...too new, I guess :)
>
> Thanks, Mark.

Heh, no probs, I'm trying to keep tabs but it ain't easy ;)

Mark

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

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

yeah, that looks like it. I wasn't aware of that issue...too new, I guess :)

Thanks, Mark.

john

Mark Hobson wrote:
| Isn't this covered by http://jira.codehaus.org/browse/MNG-932 ?
|
| Mark
|
| On 20/09/05, John Casey <[EMAIL PROTECTED]> wrote:
|
| Another solution might be an attached artifact (logically attached to
| the main .jar in the repository via the metadata) that would be
| available to other projects...so producing project A might also produce:
|
| a-version-tests.jar
|
| and you could then depend on it like such:
|
| 
| ~  some.group
| ~  a
| ~  someVersion
| ~  test-jar
| ~  test
| 
|
| would that solve the problem?
|
| -john
|
| Carsten Ziegeler wrote:
| | Dave Neuer wrote:
| |
| |>Yes, that's a workaround I'm not OK with, so a developer cannot be in
| |>/masterProject/projectA and do "m2 test," see BUILD SUCCESSFUL and think
| |>that everything is OK and check in a bunch of broken code because no
| |>tests
| |>were run -- since the tests for A don't live in A.
| |>
| |
| | Oh no, they are still in A - that's trick :) (ok, one could call it
| | hack). You have the correct pom for A containing the tests. You make a
| | sub directory in project A: "tests-for-b", add a pom.xml there
| | referencing the tests of A as src (using "../") and then it works.
| |
| |
| |>Again, I did write a maven-test-artfiact plugin which has a compile and
| |>install target; it *does* generate a test artifact (default name
| |>${artifactId}-test.${packaging}, but it's configurable.
| |>
| |>However, it doesn't generate a POM, and even w/ a manually generated
| |>one, and a declared dependancy on A's test artifact in project B,
| |>surefire doesn't run the tests in the baseclasses which reside in the
| |>test.jar.
| |>
| |>That's where I got, and where I ran out of patience and time to keep
| |>going. I'd be happy to ask my manager if we can release this code if
| |>someone else were interested in running w/ it.
| |>
| |
| | It would be interesting to hear what the m2 developers say about this
| | problem :)
| |
| | Carsten
| |

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




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



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMFyrK3h2CZwO/4URAmdkAJ9EtnA8+4q/E1y9vFW/qCzlrPueRgCeJ2Ho
OImXL7E2wJ3HxevjML4egXg=
=F56A
-END PGP SIGNATURE-

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

Re: [m2] reasons for sticking with maven

[Mark Hobson]

Isn't this covered by http://jira.codehaus.org/browse/MNG-932 ?

Mark

On 20/09/05, John Casey <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Another solution might be an attached artifact (logically attached to
> the main .jar in the repository via the metadata) that would be
> available to other projects...so producing project A might also produce:
>
> a-version-tests.jar
>
> and you could then depend on it like such:
>
> 
> ~  some.group
> ~  a
> ~  someVersion
> ~  test-jar
> ~  test
> 
>
> would that solve the problem?
>
> - -john
>
> Carsten Ziegeler wrote:
> | Dave Neuer wrote:
> |
> |>Yes, that's a workaround I'm not OK with, so a developer cannot be in
> |>/masterProject/projectA and do "m2 test," see BUILD SUCCESSFUL and think
> |>that everything is OK and check in a bunch of broken code because no
> |>tests
> |>were run -- since the tests for A don't live in A.
> |>
> |
> | Oh no, they are still in A - that's trick :) (ok, one could call it
> | hack). You have the correct pom for A containing the tests. You make a
> | sub directory in project A: "tests-for-b", add a pom.xml there
> | referencing the tests of A as src (using "../") and then it works.
> |
> |
> |>Again, I did write a maven-test-artfiact plugin which has a compile and
> |>install target; it *does* generate a test artifact (default name
> |>${artifactId}-test.${packaging}, but it's configurable.
> |>
> |>However, it doesn't generate a POM, and even w/ a manually generated
> |>one, and a declared dependancy on A's test artifact in project B,
> |>surefire doesn't run the tests in the baseclasses which reside in the
> |>test.jar.
> |>
> |>That's where I got, and where I ran out of patience and time to keep
> |>going. I'd be happy to ask my manager if we can release this code if
> |>someone else were interested in running w/ it.
> |>
> |
> | It would be interesting to hear what the m2 developers say about this
> | problem :)
> |
> | Carsten
> |
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMFs1K3h2CZwO/4URAq1eAJwMu6k7TkUiR25AcmxtHAGm77U26wCfRiBh
> uTSibc3Gno8WdJEABwrM6BM=
> =6B7J
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Another solution might be an attached artifact (logically attached to
the main .jar in the repository via the metadata) that would be
available to other projects...so producing project A might also produce:

a-version-tests.jar

and you could then depend on it like such:


~  some.group
~  a
~  someVersion
~  test-jar
~  test


would that solve the problem?

- -john

Carsten Ziegeler wrote:
| Dave Neuer wrote:
|
|>Yes, that's a workaround I'm not OK with, so a developer cannot be in
|>/masterProject/projectA and do "m2 test," see BUILD SUCCESSFUL and think
|>that everything is OK and check in a bunch of broken code because no
|>tests
|>were run -- since the tests for A don't live in A.
|>
|
| Oh no, they are still in A - that's trick :) (ok, one could call it
| hack). You have the correct pom for A containing the tests. You make a
| sub directory in project A: "tests-for-b", add a pom.xml there
| referencing the tests of A as src (using "../") and then it works.
|
|
|>Again, I did write a maven-test-artfiact plugin which has a compile and
|>install target; it *does* generate a test artifact (default name
|>${artifactId}-test.${packaging}, but it's configurable.
|>
|>However, it doesn't generate a POM, and even w/ a manually generated
|>one, and a declared dependancy on A's test artifact in project B,
|>surefire doesn't run the tests in the baseclasses which reside in the
|>test.jar.
|>
|>That's where I got, and where I ran out of patience and time to keep
|>going. I'd be happy to ask my manager if we can release this code if
|>someone else were interested in running w/ it.
|>
|
| It would be interesting to hear what the m2 developers say about this
| problem :)
|
| Carsten
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMFs1K3h2CZwO/4URAq1eAJwMu6k7TkUiR25AcmxtHAGm77U26wCfRiBh
uTSibc3Gno8WdJEABwrM6BM=
=6B7J
-END PGP SIGNATURE-

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

Re: [m2] reasons for sticking with maven

[Carsten Ziegeler]

Dave Neuer wrote:
> Yes, that's a workaround I'm not OK with, so a developer cannot be in
> /masterProject/projectA and do "m2 test," see BUILD SUCCESSFUL and think
> that everything is OK and check in a bunch of broken code because no
> tests
> were run -- since the tests for A don't live in A.
> 
Oh no, they are still in A - that's trick :) (ok, one could call it
hack). You have the correct pom for A containing the tests. You make a
sub directory in project A: "tests-for-b", add a pom.xml there
referencing the tests of A as src (using "../") and then it works.

> Again, I did write a maven-test-artfiact plugin which has a compile and
> install target; it *does* generate a test artifact (default name
> ${artifactId}-test.${packaging}, but it's configurable.
> 
> However, it doesn't generate a POM, and even w/ a manually generated
> one, and a declared dependancy on A's test artifact in project B,
> surefire doesn't run the tests in the baseclasses which reside in the
> test.jar.
> 
> That's where I got, and where I ran out of patience and time to keep
> going. I'd be happy to ask my manager if we can release this code if
> someone else were interested in running w/ it.
> 
It would be interesting to hear what the m2 developers say about this
problem :)

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

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

Re: [m2] reasons for sticking with maven

[Trygve Laugstøl]

On Tue, 2005-09-20 at 14:30 -0400, John Casey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> so, all that remains is to write that API that you need :-)
> 
> I've been thinking that we may need a sub-project within maven (with
> separated release cycle) to address plugin utility
> libraries...constructing a classloader from the project dependencies,
> executing main() methods in an isolated classloader, etc.
> 
> The plugins are going to start writing their own parallel infrastructure
> (and have in some cases) unless we can centralize it in a series of
> plugin support artifacts.
> 
> WDYT? Do you want to start a design doc for that API you need? just a
> statement of the different things it needs to do would be a good start...

You have my preliminary +1 at least.

--
Trygve


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

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

any time.

Wendell Beckwith wrote:
| I will look into commons-exec since I wasn't aware of it and thnx for all
| the help.
|
| Wb
|
|
| On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
|
| Ok, fair enough...but the maven process should probably install a
| security manager to restrict who can call System.exit(..) (i.e. no-one
| can! :)
|
| But there is still the potential for issues surrounding
| OutOfMemoryError's and the like. If you're going the route of using a
| separate java process, then you should check into commons-exec. I
| haven't used it, but if it's the stuff extracted from Ant (and plexus,
| actually), then it'll be suitable.
|
| -john
|
| Wendell Beckwith wrote:
| | True, it is a java main() call because the use ZeroG's LaunchAnywhere.
| | LaunchAnywhere creates a native executable that reads a config file that
| | lists the classpath, args and the main class to execute. However because
| I
| | didn't write the code nor do have the source code, I don't know if the
| code
| | somewhere will call System.exit(). If it does then my maven process is
| dead,
| | which is why I want the ability to run this java main() in a separate
| | process. Makes sense?
| |
| | Wb
| |
| | On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
| |
| | it's not a command line execution...it's a java main() call...right?
| |
| | Trygve Laugstøl wrote:
| | | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
| | |
| | |>I just re-read you email and I'm confused by your comment, please
| | clarify if
| | |>possible. But isn't what I've been hopefully explaining is the
| | creation of a
| | |>mojo that wraps a command line process. I have written the mojos
| | (agitate
| | |>and dashboard) an users only need to reference the plugin in their
| build
| | |>element. If the defaults are right for them, say they have a 80% code
| | |>coverage target instead of the default of 70% then they can add a
| | 
| | |>element to the  element for the plugin. Now the plugin
| | takes
| | |>the prams and puts then in the correct order and that is where I'm
| | currently
| | |>am. I would like to have a maven-java-plugin or something like it that
| | my
| | |>plugin can depend on to actually execute the process and tie its
| output
| | |>stdout and stderr back to my process. That's all I need. I'm not
| | advocating
| | |>giving users the ability to execute any java command from their pom.
| | |
| | |
| | | For now, until all the hot air in commons-exec stabilizes take a look
| at
| | | plexus-utils and the org.codehaus.plexus.util.cli package. For a
| simple
| | | example take a look at [1].
| | |
| | | [1]:
| | |
| |
| |
|
|
http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
| | |
| | | --
| | | Trygve
| | |
| | |
| | | -
| | | To unsubscribe, e-mail: [EMAIL PROTECTED]
| | | For additional commands, e-mail: [EMAIL PROTECTED]
| | |
| | |
| | |
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
|

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




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMFgcK3h2CZwO/4URAqg6AKCq6uJle+9PgQ+6gti1z0VqYTpkCACcCm04
YnPgnOM3sD7nf+8iecubZys=
=BS9H
-END PGP SIGNATURE-

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

RE: [m2] reasons for sticking with maven

[Dave Neuer]

Yes, that's a workaround I'm not OK with, so a developer cannot be in
/masterProject/projectA and do "m2 test," see BUILD SUCCESSFUL and think
that everything is OK and check in a bunch of broken code because no
tests
were run -- since the tests for A don't live in A.

Again, I did write a maven-test-artfiact plugin which has a compile and
install target; it *does* generate a test artifact (default name
${artifactId}-test.${packaging}, but it's configurable.

However, it doesn't generate a POM, and even w/ a manually generated
one, and a declared dependancy on A's test artifact in project B,
surefire doesn't run the tests in the baseclasses which reside in the
test.jar.

That's where I got, and where I ran out of patience and time to keep
going. I'd be happy to ask my manager if we can release this code if
someone else were interested in running w/ it.

Dave

-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 20, 2005 2:05 PM
To: Maven Users List
Subject: Re: [m2] reasons for sticking with maven

Dave Neuer wrote:
> 
> However, I don't like having no ability to reuse test code from one
> project in another project which depends on it. Example: project A has
> interface Blah and interface BlahDAO to persist blahs. I have
> AbstractBlahDAOTest which has testXXX methods which test *interface
> invariant* conditions of BlahDAO. Project B has a new subclass of Blah
> and BlahDAO, but it's ProjectBBlahDAO *must* still abide by the
> interface invariant constraints. So I want to have ProjectBBlahDAOTest
> which extends AbstractBlahDAOTest from project A, but I can't because
I
> can't generate another (test) artifact in maven.
> 
We experienced similar problems in Cocoon - our workaround is to add
another
project A-test which contains the all test classes as its source. Then B
can depend on A-test with scope "test". But I think this is only a
workaround. It would be great if this could be solved somehow in m2
without any tricks.

Carsten


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

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


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

Re: [m2] reasons for sticking with maven

[Wendell Beckwith]

I will look into commons-exec since I wasn't aware of it and thnx for all
the help.

Wb


On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ok, fair enough...but the maven process should probably install a
> security manager to restrict who can call System.exit(..) (i.e. no-one
> can! :)
>
> But there is still the potential for issues surrounding
> OutOfMemoryError's and the like. If you're going the route of using a
> separate java process, then you should check into commons-exec. I
> haven't used it, but if it's the stuff extracted from Ant (and plexus,
> actually), then it'll be suitable.
>
> - -john
>
> Wendell Beckwith wrote:
> | True, it is a java main() call because the use ZeroG's LaunchAnywhere.
> | LaunchAnywhere creates a native executable that reads a config file that
> | lists the classpath, args and the main class to execute. However because
> I
> | didn't write the code nor do have the source code, I don't know if the
> code
> | somewhere will call System.exit(). If it does then my maven process is
> dead,
> | which is why I want the ability to run this java main() in a separate
> | process. Makes sense?
> |
> | Wb
> |
> | On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
> |
> | it's not a command line execution...it's a java main() call...right?
> |
> | Trygve Laugstøl wrote:
> | | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
> | |
> | |>I just re-read you email and I'm confused by your comment, please
> | clarify if
> | |>possible. But isn't what I've been hopefully explaining is the
> | creation of a
> | |>mojo that wraps a command line process. I have written the mojos
> | (agitate
> | |>and dashboard) an users only need to reference the plugin in their
> build
> | |>element. If the defaults are right for them, say they have a 80% code
> | |>coverage target instead of the default of 70% then they can add a
> | 
> | |>element to the  element for the plugin. Now the plugin
> | takes
> | |>the prams and puts then in the correct order and that is where I'm
> | currently
> | |>am. I would like to have a maven-java-plugin or something like it that
> | my
> | |>plugin can depend on to actually execute the process and tie its
> output
> | |>stdout and stderr back to my process. That's all I need. I'm not
> | advocating
> | |>giving users the ability to execute any java command from their pom.
> | |
> | |
> | | For now, until all the hot air in commons-exec stabilizes take a look
> at
> | | plexus-utils and the org.codehaus.plexus.util.cli package. For a
> simple
> | | example take a look at [1].
> | |
> | | [1]:
> | |
> |
> |
>
> http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
> | |
> | | --
> | | Trygve
> | |
> | |
> | | -
> | | To unsubscribe, e-mail: [EMAIL PROTECTED]
> | | For additional commands, e-mail: [EMAIL PROTECTED]
> | |
> | |
> | |
>
> - -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMFXBK3h2CZwO/4URAvkbAJ4ir8+/w7fgWCTfH6XA0bgXLW2rmQCeKqh+
> 6H/krj8A/paO61kOgt4MHNU=
> =Lywd
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ok, fair enough...but the maven process should probably install a
security manager to restrict who can call System.exit(..) (i.e. no-one
can! :)

But there is still the potential for issues surrounding
OutOfMemoryError's and the like. If you're going the route of using a
separate java process, then you should check into commons-exec. I
haven't used it, but if it's the stuff extracted from Ant (and plexus,
actually), then it'll be suitable.

- -john

Wendell Beckwith wrote:
| True, it is a java main() call because the use ZeroG's LaunchAnywhere.
| LaunchAnywhere creates a native executable that reads a config file that
| lists the classpath, args and the main class to execute. However because I
| didn't write the code nor do have the source code, I don't know if the
code
| somewhere will call System.exit(). If it does then my maven process is
dead,
| which is why I want the ability to run this java main() in a separate
| process. Makes sense?
|
| Wb
|
| On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
|
| it's not a command line execution...it's a java main() call...right?
|
| Trygve Laugstøl wrote:
| | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
| |
| |>I just re-read you email and I'm confused by your comment, please
| clarify if
| |>possible. But isn't what I've been hopefully explaining is the
| creation of a
| |>mojo that wraps a command line process. I have written the mojos
| (agitate
| |>and dashboard) an users only need to reference the plugin in their build
| |>element. If the defaults are right for them, say they have a 80% code
| |>coverage target instead of the default of 70% then they can add a
| 
| |>element to the  element for the plugin. Now the plugin
| takes
| |>the prams and puts then in the correct order and that is where I'm
| currently
| |>am. I would like to have a maven-java-plugin or something like it that
| my
| |>plugin can depend on to actually execute the process and tie its output
| |>stdout and stderr back to my process. That's all I need. I'm not
| advocating
| |>giving users the ability to execute any java command from their pom.
| |
| |
| | For now, until all the hot air in commons-exec stabilizes take a look at
| | plexus-utils and the org.codehaus.plexus.util.cli package. For a simple
| | example take a look at [1].
| |
| | [1]:
| |
|
|
http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
| |
| | --
| | Trygve
| |
| |
| | -
| | To unsubscribe, e-mail: [EMAIL PROTECTED]
| | For additional commands, e-mail: [EMAIL PROTECTED]
| |
| |
| |

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




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMFXBK3h2CZwO/4URAvkbAJ4ir8+/w7fgWCTfH6XA0bgXLW2rmQCeKqh+
6H/krj8A/paO61kOgt4MHNU=
=Lywd
-END PGP SIGNATURE-

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

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

so, all that remains is to write that API that you need :-)

I've been thinking that we may need a sub-project within maven (with
separated release cycle) to address plugin utility
libraries...constructing a classloader from the project dependencies,
executing main() methods in an isolated classloader, etc.

The plugins are going to start writing their own parallel infrastructure
(and have in some cases) unless we can centralize it in a series of
plugin support artifacts.

WDYT? Do you want to start a design doc for that API you need? just a
statement of the different things it needs to do would be a good start...

- --john

Wendell Beckwith wrote:
| YES!! That is exactly what I need/want. Sorry if I wasn't clear
before, but
| I'm definitely not for the embedding of command lines in he pom. Now
that I
| understand where you're coming from, I can completely agree with you that
| embedding this stuff in a pom would definitely lead to cut-n-paste code
| which s why I'm actively moving nearly 100 dev's from ant to maven 2
| starting with my project.
|
| Wb
|
| On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
|
| that sounds perfectly sane, except it sounds like you only need an API
| for calling a java main() method and handling output than an actual
| plugin. Once you have that API, you're set, it sounds like...then your
| plugin can depend on that api, and give it the stream consumers for
| sterr/stout and stream provider for stdin, I guess.
|
| I suppose I misunderstood where you were going with the
| maven-java-plugin. You're after more of a main() support API than an
| actual java-plugin, since you're writing the plugin yourself. Correct?
|
| -john
|
| Wendell Beckwith wrote:
| | I just re-read you email and I'm confused by your comment, please
| clarify if
| | possible. But isn't what I've been hopefully explaining is the
| creation of a
| | mojo that wraps a command line process. I have written the mojos
| (agitate
| | and dashboard) an users only need to reference the plugin in their build
| | element. If the defaults are right for them, say they have a 80% code
| | coverage target instead of the default of 70% then they can add a
| 
| | element to the  element for the plugin. Now the plugin
| takes
| | the prams and puts then in the correct order and that is where I'm
| currently
| | am. I would like to have a maven-java-plugin or something like it that
| my
| | plugin can depend on to actually execute the process and tie its output
| | stdout and stderr back to my process. That's all I need. I'm not
| advocating
| | giving users the ability to execute any java command from their pom.
| |
| | This is my 1st m2 plugin so if I'm now one of those clueless users, then
| | please correct me where I'm wrong.
| |
| | Wb
| | On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
| |
| |>-BEGIN PGP SIGNED MESSAGE-
| |>Hash: SHA1
| |>
| |>
| |>I guess I don't understand what's wrong with writing mojos to wrap
| |>specific command-line-driven use cases...?
| |>
| |>- -john
| |>
| |
| |

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




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMFU/K3h2CZwO/4URAqnnAKCs5kWQ/8rkJHwUP4F8ZpMI07Lq4ACeNmbg
ygQnRvqcld3CuQ/4MuZZfbU=
=LOuS
-END PGP SIGNATURE-

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

Re: [m2] reasons for sticking with maven

[Trygve Laugstøl]

On Tue, 2005-09-20 at 14:17 -0400, John Casey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> it's not a command line execution...it's a java main() call...right?

Oh, if so I misunderstood, oh well.

--
Trygve


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

Re: [m2] reasons for sticking with maven

[Wendell Beckwith]

True, it is a java main() call because the use ZeroG's LaunchAnywhere.
LaunchAnywhere creates a native executable that reads a config file that
lists the classpath, args and the main class to execute. However because I
didn't write the code nor do have the source code, I don't know if the code
somewhere will call System.exit(). If it does then my maven process is dead,
which is why I want the ability to run this java main() in a separate
process. Makes sense?

Wb

On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> it's not a command line execution...it's a java main() call...right?
>
> Trygve Laugstøl wrote:
> | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
> |
> |>I just re-read you email and I'm confused by your comment, please
> clarify if
> |>possible. But isn't what I've been hopefully explaining is the
> creation of a
> |>mojo that wraps a command line process. I have written the mojos
> (agitate
> |>and dashboard) an users only need to reference the plugin in their build
> |>element. If the defaults are right for them, say they have a 80% code
> |>coverage target instead of the default of 70% then they can add a
> 
> |>element to the  element for the plugin. Now the plugin
> takes
> |>the prams and puts then in the correct order and that is where I'm
> currently
> |>am. I would like to have a maven-java-plugin or something like it that
> my
> |>plugin can depend on to actually execute the process and tie its output
> |>stdout and stderr back to my process. That's all I need. I'm not
> advocating
> |>giving users the ability to execute any java command from their pom.
> |
> |
> | For now, until all the hot air in commons-exec stabilizes take a look at
> | plexus-utils and the org.codehaus.plexus.util.cli package. For a simple
> | example take a look at [1].
> |
> | [1]:
> |
>
> http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
> |
> | --
> | Trygve
> |
> |
> | -
> | To unsubscribe, e-mail: [EMAIL PROTECTED]
> | For additional commands, e-mail: [EMAIL PROTECTED]
> |
> |
> |
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMFI/K3h2CZwO/4URAvoXAKCpFFlfc7CDSG35HygJdqAN0aHfbgCeMMzA
> bc1WTt3I4WBoJycsmRICNXc=
> =rA82
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

it's not a command line execution...it's a java main() call...right?

Trygve Laugstøl wrote:
| On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
|
|>I just re-read you email and I'm confused by your comment, please
clarify if
|>possible. But isn't what I've been hopefully explaining is the
creation of a
|>mojo that wraps a command line process. I have written the mojos (agitate
|>and dashboard) an users only need to reference the plugin in their build
|>element. If the defaults are right for them, say they have a 80% code
|>coverage target instead of the default of 70% then they can add a

|>element to the  element for the plugin. Now the plugin
takes
|>the prams and puts then in the correct order and that is where I'm
currently
|>am. I would like to have a maven-java-plugin or something like it that my
|>plugin can depend on to actually execute the process and tie its output
|>stdout and stderr back to my process. That's all I need. I'm not
advocating
|>giving users the ability to execute any java command from their pom.
|
|
| For now, until all the hot air in commons-exec stabilizes take a look at
| plexus-utils and the org.codehaus.plexus.util.cli package. For a simple
| example take a look at [1].
|
| [1]:
|
http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
|
| --
| Trygve
|
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMFI/K3h2CZwO/4URAvoXAKCpFFlfc7CDSG35HygJdqAN0aHfbgCeMMzA
bc1WTt3I4WBoJycsmRICNXc=
=rA82
-END PGP SIGNATURE-

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

Re: [m2] reasons for sticking with maven

[Wendell Beckwith]

YES!! That is exactly what I need/want. Sorry if I wasn't clear before, but
I'm definitely not for the embedding of command lines in he pom. Now that I
understand where you're coming from, I can completely agree with you that
embedding this stuff in a pom would definitely lead to cut-n-paste code
which s why I'm actively moving nearly 100 dev's from ant to maven 2
starting with my project.

Wb

On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> that sounds perfectly sane, except it sounds like you only need an API
> for calling a java main() method and handling output than an actual
> plugin. Once you have that API, you're set, it sounds like...then your
> plugin can depend on that api, and give it the stream consumers for
> sterr/stout and stream provider for stdin, I guess.
>
> I suppose I misunderstood where you were going with the
> maven-java-plugin. You're after more of a main() support API than an
> actual java-plugin, since you're writing the plugin yourself. Correct?
>
> - -john
>
> Wendell Beckwith wrote:
> | I just re-read you email and I'm confused by your comment, please
> clarify if
> | possible. But isn't what I've been hopefully explaining is the
> creation of a
> | mojo that wraps a command line process. I have written the mojos
> (agitate
> | and dashboard) an users only need to reference the plugin in their build
> | element. If the defaults are right for them, say they have a 80% code
> | coverage target instead of the default of 70% then they can add a
> 
> | element to the  element for the plugin. Now the plugin
> takes
> | the prams and puts then in the correct order and that is where I'm
> currently
> | am. I would like to have a maven-java-plugin or something like it that
> my
> | plugin can depend on to actually execute the process and tie its output
> | stdout and stderr back to my process. That's all I need. I'm not
> advocating
> | giving users the ability to execute any java command from their pom.
> |
> | This is my 1st m2 plugin so if I'm now one of those clueless users, then
> | please correct me where I'm wrong.
> |
> | Wb
> | On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
> |
> |>-BEGIN PGP SIGNED MESSAGE-
> |>Hash: SHA1
> |>
> |>
> |>I guess I don't understand what's wrong with writing mojos to wrap
> |>specific command-line-driven use cases...?
> |>
> |>- -john
> |>
> |
> |
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMFEWK3h2CZwO/4URAveWAKCDHwHQN8WHKYx0V7YtI1mto4x4mgCdG+v9
> pTLGzK9uJsmhto/wMtt1+vo=
> =NYSU
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [m2] reasons for sticking with maven

[Trygve Laugstøl]

On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
> I just re-read you email and I'm confused by your comment, please clarify if
> possible. But isn't what I've been hopefully explaining is the creation of a
> mojo that wraps a command line process. I have written the mojos (agitate
> and dashboard) an users only need to reference the plugin in their build
> element. If the defaults are right for them, say they have a 80% code
> coverage target instead of the default of 70% then they can add a 
> element to the  element for the plugin. Now the plugin takes
> the prams and puts then in the correct order and that is where I'm currently
> am. I would like to have a maven-java-plugin or something like it that my
> plugin can depend on to actually execute the process and tie its output
> stdout and stderr back to my process. That's all I need. I'm not advocating
> giving users the ability to execute any java command from their pom.

For now, until all the hot air in commons-exec stabilizes take a look at
plexus-utils and the org.codehaus.plexus.util.cli package. For a simple
example take a look at [1].

[1]:
http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup

--
Trygve


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

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

that sounds perfectly sane, except it sounds like you only need an API
for calling a java main() method and handling output than an actual
plugin. Once you have that API, you're set, it sounds like...then your
plugin can depend on that api, and give it the stream consumers for
sterr/stout and stream provider for stdin, I guess.

I suppose I misunderstood where you were going with the
maven-java-plugin. You're after more of a main() support API than an
actual java-plugin, since you're writing the plugin yourself. Correct?

- -john

Wendell Beckwith wrote:
| I just re-read you email and I'm confused by your comment, please
clarify if
| possible. But isn't what I've been hopefully explaining is the
creation of a
| mojo that wraps a command line process. I have written the mojos (agitate
| and dashboard) an users only need to reference the plugin in their build
| element. If the defaults are right for them, say they have a 80% code
| coverage target instead of the default of 70% then they can add a

| element to the  element for the plugin. Now the plugin
takes
| the prams and puts then in the correct order and that is where I'm
currently
| am. I would like to have a maven-java-plugin or something like it that my
| plugin can depend on to actually execute the process and tie its output
| stdout and stderr back to my process. That's all I need. I'm not
advocating
| giving users the ability to execute any java command from their pom.
|
| This is my 1st m2 plugin so if I'm now one of those clueless users, then
| please correct me where I'm wrong.
|
| Wb
| On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
|
|>-BEGIN PGP SIGNED MESSAGE-
|>Hash: SHA1
|>
|>
|>I guess I don't understand what's wrong with writing mojos to wrap
|>specific command-line-driven use cases...?
|>
|>- -john
|>
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMFEWK3h2CZwO/4URAveWAKCDHwHQN8WHKYx0V7YtI1mto4x4mgCdG+v9
pTLGzK9uJsmhto/wMtt1+vo=
=NYSU
-END PGP SIGNATURE-

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

Re: [m2] reasons for sticking with maven

[Wendell Beckwith]

I just re-read you email and I'm confused by your comment, please clarify if
possible. But isn't what I've been hopefully explaining is the creation of a
mojo that wraps a command line process. I have written the mojos (agitate
and dashboard) an users only need to reference the plugin in their build
element. If the defaults are right for them, say they have a 80% code
coverage target instead of the default of 70% then they can add a 
element to the  element for the plugin. Now the plugin takes
the prams and puts then in the correct order and that is where I'm currently
am. I would like to have a maven-java-plugin or something like it that my
plugin can depend on to actually execute the process and tie its output
stdout and stderr back to my process. That's all I need. I'm not advocating
giving users the ability to execute any java command from their pom.

This is my 1st m2 plugin so if I'm now one of those clueless users, then
please correct me where I'm wrong.

Wb
On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> I guess I don't understand what's wrong with writing mojos to wrap
> specific command-line-driven use cases...?
>
> - -john
>

Re: Announcements mailing list

[Trygve Laugstøl]

On Tue, 2005-09-20 at 10:52 -0700, Richard Wallace wrote:
> Jason van Zyl wrote:
> > We use the announce@apache.org for this. It's relatively low traffic,
> > but we probably won't create an announcement list specifically for Maven
> > itself.
> >   
> Ah I see.  Didn't know that.  Should probably be mentioned on the 
> mailing lists page for people like me.  Guess I'll go subscribe to that one.

Done, thanks.

--
Trygve



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

Re: [m2] reasons for sticking with maven

[Carsten Ziegeler]

Dave Neuer wrote:
> 
> However, I don't like having no ability to reuse test code from one
> project in another project which depends on it. Example: project A has
> interface Blah and interface BlahDAO to persist blahs. I have
> AbstractBlahDAOTest which has testXXX methods which test *interface
> invariant* conditions of BlahDAO. Project B has a new subclass of Blah
> and BlahDAO, but it's ProjectBBlahDAO *must* still abide by the
> interface invariant constraints. So I want to have ProjectBBlahDAOTest
> which extends AbstractBlahDAOTest from project A, but I can't because I
> can't generate another (test) artifact in maven.
> 
We experienced similar problems in Cocoon - our workaround is to add another
project A-test which contains the all test classes as its source. Then B
can depend on A-test with scope "test". But I think this is only a
workaround. It would be great if this could be solved somehow in m2
without any tricks.

Carsten


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

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

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I was actually referring to a couple of implementation patterns.

1. Wrap a command-line invocation.

~  Using commons-exec or any other Runtime.exec() wrapper, you can build
a mojo that will pull in parameters from the Maven build process, format
the command line, and execute...hopefully with output/error handling for
that specific command.

2. Provide a plugin wrapper for an Ant script.

~  Using a given Ant script, bundle that script into a maven plugin whose
functionality is centered on that single script. Again, maven provides
the parameters from the build process, and passes them to the
script/target in that plugin's embedded Ant script. Again, output/errors
are handled in a way that is tuned to the task at hand.

It's important to understand the specificity of these solutions. If
you're using a general directly-embedded-Ant-inside-the-POM solution,
you cannot handle output or errors in an intelligent manner. Same with a
command-line-inside-the-POM solution. Moreover, in each of these inline
solutions, your specific command-line or Ant invocation is confined to
that POM and possibly its descendents, via inheritance. You cannot reuse
this configuration outside the POM without incurring the costs of
maintenance associated with cut-and-paste programming of any kind (i.e.
multiple maintenance points, propagation of erroneous code, etc.).

I'm not familiar with the plugin you've written, but I think the above
statements apply generally. If you're already following those
principles, I'd like to see what you have. I've been heads-down lately,
so I may have missed the thread in which you were talking about it...

Of course, using (or abusing) the maven plugin framework, you can do
almost anything. Just don't ask me to maintain it or support it... :)

Cheers,

john

Wendell Beckwith wrote:
| Just for clarification are you suggesting that a plugin that needs to
| execute a java process should be designed as an ant script, and the plugin
| would simply pass parameters to the ant script? I ask because I don't see
| how this is less maintenance than my current plugin that provides
| intelligent defaults in the mojo and just needs to pass theses parameters
| along with any the user changed to the java process. Whenever there are
| plugin changes, I still go to the mojo in my design or an ant script
in your
| design, correct?
|
| Wb
|
|
| On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
|
| I've actually done something just like this in the past, in order to
| call a Make-based build. IMO, you want to wrap a command line call in a
| plugin, to formalize the parameters - required and optional - which
| constitutes a valid invocation of that executable. Otherwise, it's prone
| to breaking, misuse, and cut-and-paste maintenance style. In short, it
| isn't robust, and doesn't scale well. Anything where execution logic is
| embedded in the POM will suffer from this, IMO - including the antrun
| and execute plugins in the mojos project. A better solution for Ant
| would be to build the plugin around the Ant script/scriptlet, and bundle
| that script into the plugin jar...then parameterize the input
| configuration. Then, the script can climb the maturity curve, and is
| truly reused with a single point of maintenance.
|
| -john
|
| Vincent Massol wrote:
| |
| |>-Original Message-
| |>From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
| |>Sent: mardi 20 septembre 2005 19:15
| |>To: Maven Users List
| |>Subject: Re: [m2] reasons for sticking with maven
| |>
| |>John is basically stating the very thing that I'm against in the
| statement
| |>below. I have a 3rd party command line utility from
| |>www.agitar.com ,
| |>that basically does unit tests against our code. I want to write (and
| have
| |>started writing) an M2 plugin to execute the java command line for the
| |>agitation process from my plugin. All I need now to complete my plugin
| |>besides more hours in a day is a plugin that will allow me to execute a
| |>java
| |>command line. Now my plugin will integrate with the maven lifecycle
| during
| |>the test phase. However, first I'm told to use the maven-execute-plugin
| |>and
| |>then another dev states that it's bad and wants to see it eliminated,
| I'm
| |>left thinking WTF!? This *helps* me adopt maven and the process, not
| |>hinders
| |>it. My whole purpose for writing the plugin was so that I could make the
| |>plugin once and the other groups here and else where since I would open
| |>source it would be able to reuse it. Is this not what maven is for?
| |
| |
| | Just to muddy the waters: why don't you use commons-exec from your
| plugin's
| | java code to execute your process?
| |
| | [snip]
| |
| | Thanks
| | -Vincent
| |
| |
| | -
| | To unsubscribe, e-mail: [EMAIL PROTECTED]
| | For additional commands, e-mail: [EMAIL PROTECTED]
| |
| |
|

Re: [m2] reasons for sticking with maven

[Wendell Beckwith]

On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1



If you're forced to run unit tests via a main() invocation, why not
> write a unit-test plugin that calls this type of test, and formats
> errors/output so it can be integrated into the unit tests reporting
> features, rather than write a plugin that's sole aim is one-off, custom
> configuration on a per-POM basis, and has no hope of ever being reusable
> or scalable?


Oh, this is simple because I have encountered it before. The main reason I
have to have a separate process is because some developers are not
enlightened enough to just throw an exception and instead they'll dump
something in a log and them call System.exit(). Thus, I can't run their code
in my process. Another case is where a you need to run a process across a
series of resources (i.e. files) one at a time, perhaps for code generation.
Some processes may load native libraries and you can't have then loading a
library more than once in a process's lifetime, so you again need to run
this in a separate process.

I guess I don't understand what's wrong with writing mojos to wrap
> specific command-line-driven use cases...?
>
> - -john
>
> Wendell Beckwith wrote:
> | Probably because I'm not aware of what your talking about. Nonetheless,
> | while there may be another way of doing what I need, the ability to
> simple
> | specify a command line to a java process that is something that has
> | tremendous capability. Can users overdo it sure, but in an effort to
> protect
> | clueless users from themselves, should we prevent more advances
> users/plugin
> | developers from achieving their needs. I'm a big eclipse and firefox
> user,
> | but I don't dictate that everyone on my team has to do as I do because I
> | believe it is the "one true way" for IDEs and web browsing.
> |
> | Wb
> |
> | On 9/20/05, Vincent Massol <[EMAIL PROTECTED]> wrote:
> |
> |>
> |>
> |>>-Original Message-
> |>>From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
> |>>Sent: mardi 20 septembre 2005 19:15
> |>>To: Maven Users List
> |>>Subject: Re: [m2] reasons for sticking with maven
> |>>
> |>>John is basically stating the very thing that I'm against in the
> |>
> |>statement
> |>
> |>>below. I have a 3rd party command line utility from
> |>>www.agitar.com  <
> http://www.agitar.com>,
> |>>that basically does unit tests against our code. I want to write (and
> |>
> |>have
> |>
> |>>started writing) an M2 plugin to execute the java command line for the
> |>>agitation process from my plugin. All I need now to complete my plugin
> |>>besides more hours in a day is a plugin that will allow me to execute a
> |>>java
> |>>command line. Now my plugin will integrate with the maven lifecycle
> |>
> |>during
> |>
> |>>the test phase. However, first I'm told to use the maven-execute-plugin
> |>>and
> |>>then another dev states that it's bad and wants to see it eliminated,
> |>
> |>I'm
> |>
> |>>left thinking WTF!? This *helps* me adopt maven and the process, not
> |>>hinders
> |>>it. My whole purpose for writing the plugin was so that I could make
> the
> |>>plugin once and the other groups here and else where since I would open
> |>>source it would be able to reuse it. Is this not what maven is for?
> |>
> |>Just to muddy the waters: why don't you use commons-exec from your
> |>plugin's
> |>java code to execute your process?
> |>
> |>[snip]
> |>
> |>Thanks
> |>-Vincent
> |>
> |>
> |>-
> |>To unsubscribe, e-mail: [EMAIL PROTECTED]
> |>For additional commands, e-mail: [EMAIL PROTECTED]
> |>
> |>
> |
> |
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMEkBK3h2CZwO/4URAkV4AJ91AZVpovMtVrVziGZGb1dBKOQv2wCfSrY9
> oShApxHT8sNeu/om38WwQKY=
> =kv4h
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Announcements mailing list

[Richard Wallace]

Jason van Zyl wrote:

We use the announce@apache.org for this. It's relatively low traffic,
but we probably won't create an announcement list specifically for Maven
itself.
  
Ah I see.  Didn't know that.  Should probably be mentioned on the 
mailing lists page for people like me.  Guess I'll go subscribe to that one.


Thanks again,
Rich

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

Re: [m2] reasons for sticking with maven

[Wendell Beckwith]

Just for clarification are you suggesting that a plugin that needs to
execute a java process should be designed as an ant script, and the plugin
would simply pass parameters to the ant script? I ask because I don't see
how this is less maintenance than my current plugin that provides
intelligent defaults in the mojo and just needs to pass theses parameters
along with any the user changed to the java process. Whenever there are
plugin changes, I still go to the mojo in my design or an ant script in your
design, correct?

Wb


On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I've actually done something just like this in the past, in order to
> call a Make-based build. IMO, you want to wrap a command line call in a
> plugin, to formalize the parameters - required and optional - which
> constitutes a valid invocation of that executable. Otherwise, it's prone
> to breaking, misuse, and cut-and-paste maintenance style. In short, it
> isn't robust, and doesn't scale well. Anything where execution logic is
> embedded in the POM will suffer from this, IMO - including the antrun
> and execute plugins in the mojos project. A better solution for Ant
> would be to build the plugin around the Ant script/scriptlet, and bundle
> that script into the plugin jar...then parameterize the input
> configuration. Then, the script can climb the maturity curve, and is
> truly reused with a single point of maintenance.
>
> - -john
>
> Vincent Massol wrote:
> |
> |>-Original Message-
> |>From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
> |>Sent: mardi 20 septembre 2005 19:15
> |>To: Maven Users List
> |>Subject: Re: [m2] reasons for sticking with maven
> |>
> |>John is basically stating the very thing that I'm against in the
> statement
> |>below. I have a 3rd party command line utility from
> |>www.agitar.com ,
> |>that basically does unit tests against our code. I want to write (and
> have
> |>started writing) an M2 plugin to execute the java command line for the
> |>agitation process from my plugin. All I need now to complete my plugin
> |>besides more hours in a day is a plugin that will allow me to execute a
> |>java
> |>command line. Now my plugin will integrate with the maven lifecycle
> during
> |>the test phase. However, first I'm told to use the maven-execute-plugin
> |>and
> |>then another dev states that it's bad and wants to see it eliminated,
> I'm
> |>left thinking WTF!? This *helps* me adopt maven and the process, not
> |>hinders
> |>it. My whole purpose for writing the plugin was so that I could make the
> |>plugin once and the other groups here and else where since I would open
> |>source it would be able to reuse it. Is this not what maven is for?
> |
> |
> | Just to muddy the waters: why don't you use commons-exec from your
> plugin's
> | java code to execute your process?
> |
> | [snip]
> |
> | Thanks
> | -Vincent
> |
> |
> | -
> | To unsubscribe, e-mail: [EMAIL PROTECTED]
> | For additional commands, e-mail: [EMAIL PROTECTED]
> |
> |
> |
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
> 3JIbhwsALTmuwn5OB/7gG9k=
> =WOfH
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [m2] reasons for sticking with maven

[Chris Berry]

Ashley,
I recommend that you pull my AntFile Plugin (as a ZIP) from the M2
Jira. I think you will see that this provides exactly what you're
asking for -- a simple, clean blending of Ant w/ Maven (Included is an
Axis WSDL2Java plugin that demonstrates it's usage pattern). You
script with Ant, roll the script into a reusable Plugin, and execute
your script (via the Plugin) from the appropriate Maven Phase.
Cheers,
-- Chris

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

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

No one is saying you have to follow the party line here. You're free to
develop your own maven plugins to solve any problem you like, even run
your toaster if you want. Maven will load your plugin, provided you add
your groupId to the list of pluginGroups in the settings.xml. We just
don't want to be in the business of building a tool to allow non-build
activities, because it muddies up our concept of what's really involved
with building software. There are multiple boundary considerations for
this process, where integrating with maven makes sense, but let's be
frank here...they aren't really _build_ process activities.

If you're forced to run unit tests via a main() invocation, why not
write a unit-test plugin that calls this type of test, and formats
errors/output so it can be integrated into the unit tests reporting
features, rather than write a plugin that's sole aim is one-off, custom
configuration on a per-POM basis, and has no hope of ever being reusable
or scalable?

I guess I don't understand what's wrong with writing mojos to wrap
specific command-line-driven use cases...?

- -john

Wendell Beckwith wrote:
| Probably because I'm not aware of what your talking about. Nonetheless,
| while there may be another way of doing what I need, the ability to simple
| specify a command line to a java process that is something that has
| tremendous capability. Can users overdo it sure, but in an effort to
protect
| clueless users from themselves, should we prevent more advances
users/plugin
| developers from achieving their needs. I'm a big eclipse and firefox user,
| but I don't dictate that everyone on my team has to do as I do because I
| believe it is the "one true way" for IDEs and web browsing.
|
| Wb
|
| On 9/20/05, Vincent Massol <[EMAIL PROTECTED]> wrote:
|
|>
|>
|>>-Original Message-
|>>From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
|>>Sent: mardi 20 septembre 2005 19:15
|>>To: Maven Users List
|>>Subject: Re: [m2] reasons for sticking with maven
|>>
|>>John is basically stating the very thing that I'm against in the
|>
|>statement
|>
|>>below. I have a 3rd party command line utility from
|>>www.agitar.com ,
|>>that basically does unit tests against our code. I want to write (and
|>
|>have
|>
|>>started writing) an M2 plugin to execute the java command line for the
|>>agitation process from my plugin. All I need now to complete my plugin
|>>besides more hours in a day is a plugin that will allow me to execute a
|>>java
|>>command line. Now my plugin will integrate with the maven lifecycle
|>
|>during
|>
|>>the test phase. However, first I'm told to use the maven-execute-plugin
|>>and
|>>then another dev states that it's bad and wants to see it eliminated,
|>
|>I'm
|>
|>>left thinking WTF!? This *helps* me adopt maven and the process, not
|>>hinders
|>>it. My whole purpose for writing the plugin was so that I could make the
|>>plugin once and the other groups here and else where since I would open
|>>source it would be able to reuse it. Is this not what maven is for?
|>
|>Just to muddy the waters: why don't you use commons-exec from your
|>plugin's
|>java code to execute your process?
|>
|>[snip]
|>
|>Thanks
|>-Vincent
|>
|>
|>-
|>To unsubscribe, e-mail: [EMAIL PROTECTED]
|>For additional commands, e-mail: [EMAIL PROTECTED]
|>
|>
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMEkBK3h2CZwO/4URAkV4AJ91AZVpovMtVrVziGZGb1dBKOQv2wCfSrY9
oShApxHT8sNeu/om38WwQKY=
=kv4h
-END PGP SIGNATURE-

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

Re: Announcements mailing list

[Jason van Zyl]

On Tue, 2005-09-20 at 10:32 -0700, Richard Wallace wrote:
> Hello,
> 
> With the continued development on maven 1.1 and 2.0 and continuum it 
> would be nice to have an announcements mailing list so that people can 
> be notified when things are released.  I mean, I'm not a regular user 
> mailing list subscriber and I don't visit the maven site often because 
> maven 1.0.2 "Just works" for everything that I need it to do. 
> 
> I just happened to be going through all the projects that I'd be 
> interested in being notified of new releases of this morning and 
> happened to see the announcements of maven 2.0 beta1 and continuum 
> alpha4.  If I hadn't happened to be looking for an announcements mailing 
> list I never would have known about either of these releases and since I 
> don't regular visit the site or subscribe to the mailing list I probably 
> wouldn't have known for quite some time.
> 
> Any chance on making this happen?

We use the announce@apache.org for this. It's relatively low traffic,
but we probably won't create an announcement list specifically for Maven
itself.

> Thanks,
> Rich
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition


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

RE: [m2] reasons for sticking with maven

[Jason van Zyl]

On Tue, 2005-09-20 at 11:52 -0400, Dave Neuer wrote:

> To which I have to say: why the hell did someone develop surefire in the
> first place? 

Short answer: classloader issues. Longer answer is that I wanted
something like SuiteRunner which Surefire is based on:

http://www.artima.com/suiterunner/

Surefire runs JUnit tests but also has its own notion of a unit of
testing called a Battery which easily allows things like scripted
testing. There's a Jython battery for example.

> There's already a perfectly good Ant junit task? 

It does work perfectly from Ant. Surefire was written a long time ago
and Ant's classloading might be fixed now but classloading was one of
the primary reasons.

> And why
> their own microcontainer? What the heck was wrong w/ Spring (which lots
> of people already use).

Spring was not on the radar when Plexus was started. Plexus came about
out of my experience with the Avalon project. That said we are looking
at things like Spring and OSGi.

> It seems to me to be a codehaus thing: a propensity to eschew reuse of
> other people's code.

To a certain extent sure, but there really weren't any mature containers
at the time m2 was started. It's been in development longer then most
think.

> So, the upshot is, my plugin doesn't work. It wouldn't work outside of
> m2 anyway (since m2 plugins don't rely on normal Java mechanisms -- like
> setter injection, to set their properties)

They do now. We felt that was important as other folks have asked that
too so we fixed it.

>  so it's not really general as
> I've heard claimed by some here as an argument why maven plugins are
> good - loosely coupled to maven. And to make it work, I might have to
> hack surefire. And plexus. And whatever other 20 wheels have been
> reinvented rather than reused.

We are earnestly trying to roll things in Plexus back into projects like
Jakarta Commons. We've done this with the compiler components we've made
(which I originally lifted from Cocoon) and our exec code. Slowly we
will integrate much of our code back into like Jakarta Commons where
things are more easily shared. Much of the reimplementation is due to me
lifting stuff and hacking it just to get things to work. Brett has
spearheaded the effort to move much of the code used in Maven back to
Jakarta from Plexus and it's not an easy task.

Ideally what we would like is to have all the utility code in Ant and
Plexus back in Jakarta Commons where it can all be maintained for
everyone's benefit.

> I realise that some of the above may be perceived as somewhat
> inflammatory, but it's really just born out of the frustration of seeing
> what seems like it should be an easy task -- one which I *can't imagine*
> I'm the only one requiring -- be so difficult.

Fair enough, this is the kind of feedback we need in order to correct
the deficiencies. I think the last couple posts by yourself and Ashley
are great as you've taken some care in expressing what difficulties
you're running into and we can't fix this stuff without feedback. So
thanks.

> And since I don't really have more time to steal from my project to
> devote to the maven plugin development task, I'm left looking for
> alternatives, or reluctantly planning to rewrite the build process in
> Ant buildfiles in the not too distant future.

We're usually pretty helpful in IRC and here if you want to toss around
ideas. I don't think what you're trying to do would stump us for long if
it's not already possible.

> Respectfully but w/ frustration and confusion,
> Dave
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

We know what we are, but know not what we may be.

  -- Shakespeare


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

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've actually done something just like this in the past, in order to
call a Make-based build. IMO, you want to wrap a command line call in a
plugin, to formalize the parameters - required and optional - which
constitutes a valid invocation of that executable. Otherwise, it's prone
to breaking, misuse, and cut-and-paste maintenance style. In short, it
isn't robust, and doesn't scale well. Anything where execution logic is
embedded in the POM will suffer from this, IMO - including the antrun
and execute plugins in the mojos project. A better solution for Ant
would be to build the plugin around the Ant script/scriptlet, and bundle
that script into the plugin jar...then parameterize the input
configuration. Then, the script can climb the maturity curve, and is
truly reused with a single point of maintenance.

- -john

Vincent Massol wrote:
|
|>-Original Message-
|>From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
|>Sent: mardi 20 septembre 2005 19:15
|>To: Maven Users List
|>Subject: Re: [m2] reasons for sticking with maven
|>
|>John is basically stating the very thing that I'm against in the statement
|>below. I have a 3rd party command line utility from
|>www.agitar.com,
|>that basically does unit tests against our code. I want to write (and have
|>started writing) an M2 plugin to execute the java command line for the
|>agitation process from my plugin. All I need now to complete my plugin
|>besides more hours in a day is a plugin that will allow me to execute a
|>java
|>command line. Now my plugin will integrate with the maven lifecycle during
|>the test phase. However, first I'm told to use the maven-execute-plugin
|>and
|>then another dev states that it's bad and wants to see it eliminated, I'm
|>left thinking WTF!? This *helps* me adopt maven and the process, not
|>hinders
|>it. My whole purpose for writing the plugin was so that I could make the
|>plugin once and the other groups here and else where since I would open
|>source it would be able to reuse it. Is this not what maven is for?
|
|
| Just to muddy the waters: why don't you use commons-exec from your
plugin's
| java code to execute your process?
|
| [snip]
|
| Thanks
| -Vincent
|
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
3JIbhwsALTmuwn5OB/7gG9k=
=WOfH
-END PGP SIGNATURE-

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

Announcements mailing list

[Richard Wallace]

Hello,

With the continued development on maven 1.1 and 2.0 and continuum it 
would be nice to have an announcements mailing list so that people can 
be notified when things are released.  I mean, I'm not a regular user 
mailing list subscriber and I don't visit the maven site often because 
maven 1.0.2 "Just works" for everything that I need it to do. 

I just happened to be going through all the projects that I'd be 
interested in being notified of new releases of this morning and 
happened to see the announcements of maven 2.0 beta1 and continuum 
alpha4.  If I hadn't happened to be looking for an announcements mailing 
list I never would have known about either of these releases and since I 
don't regular visit the site or subscribe to the mailing list I probably 
wouldn't have known for quite some time.


Any chance on making this happen?

Thanks,
Rich

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

Re: [m2] reasons for sticking with maven

[Wendell Beckwith]

Probably because I'm not aware of what your talking about. Nonetheless,
while there may be another way of doing what I need, the ability to simple
specify a command line to a java process that is something that has
tremendous capability. Can users overdo it sure, but in an effort to protect
clueless users from themselves, should we prevent more advances users/plugin
developers from achieving their needs. I'm a big eclipse and firefox user,
but I don't dictate that everyone on my team has to do as I do because I
believe it is the "one true way" for IDEs and web browsing.

Wb

On 9/20/05, Vincent Massol <[EMAIL PROTECTED]> wrote:
>
>
>
> > -Original Message-
> > From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
> > Sent: mardi 20 septembre 2005 19:15
> > To: Maven Users List
> > Subject: Re: [m2] reasons for sticking with maven
> >
> > John is basically stating the very thing that I'm against in the
> statement
> > below. I have a 3rd party command line utility from
> > www.agitar.com ,
> > that basically does unit tests against our code. I want to write (and
> have
> > started writing) an M2 plugin to execute the java command line for the
> > agitation process from my plugin. All I need now to complete my plugin
> > besides more hours in a day is a plugin that will allow me to execute a
> > java
> > command line. Now my plugin will integrate with the maven lifecycle
> during
> > the test phase. However, first I'm told to use the maven-execute-plugin
> > and
> > then another dev states that it's bad and wants to see it eliminated,
> I'm
> > left thinking WTF!? This *helps* me adopt maven and the process, not
> > hinders
> > it. My whole purpose for writing the plugin was so that I could make the
> > plugin once and the other groups here and else where since I would open
> > source it would be able to reuse it. Is this not what maven is for?
>
> Just to muddy the waters: why don't you use commons-exec from your
> plugin's
> java code to execute your process?
>
> [snip]
>
> Thanks
> -Vincent
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

RE: [m2] reasons for sticking with maven

[Vincent Massol]

> -Original Message-
> From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
> Sent: mardi 20 septembre 2005 19:15
> To: Maven Users List
> Subject: Re: [m2] reasons for sticking with maven
> 
> John is basically stating the very thing that I'm against in the statement
> below. I have a 3rd party command line utility from
> www.agitar.com,
> that basically does unit tests against our code. I want to write (and have
> started writing) an M2 plugin to execute the java command line for the
> agitation process from my plugin. All I need now to complete my plugin
> besides more hours in a day is a plugin that will allow me to execute a
> java
> command line. Now my plugin will integrate with the maven lifecycle during
> the test phase. However, first I'm told to use the maven-execute-plugin
> and
> then another dev states that it's bad and wants to see it eliminated, I'm
> left thinking WTF!? This *helps* me adopt maven and the process, not
> hinders
> it. My whole purpose for writing the plugin was so that I could make the
> plugin once and the other groups here and else where since I would open
> source it would be able to reuse it. Is this not what maven is for?

Just to muddy the waters: why don't you use commons-exec from your plugin's
java code to execute your process?

[snip]

Thanks
-Vincent


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

RE: ejb and war plugins (maven 1.1 beta2)

[Vincent Massol]

> -Original Message-
> From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
> Sent: mardi 20 septembre 2005 18:10
> To: Maven Users List
> Subject: Re: ejb and war plugins (maven 1.1 beta2)
> 
> He should add a requirement for the war plugin.
> I'll see with him..

I've just done that and committed the change. Sorry again and thanks guys
for fixing this :-)

-Vincent

> On 9/20/05, jan_bar <[EMAIL PROTECTED]> wrote:
> >
> > Thanks for your time Arnaud, it works for me. Vincent should fix code
> for
> > http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html?page=4
> >
> > Jan
> >
> > "Arnaud HERITIER" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > I published a snapshot
> > you can install it locally
> > maven plugin:download
> > -Dmaven.repo.remote=http:www.ibiblio.org/maven,
> > http://cvs.apache.org/reposit
> > ory/
> > -DgroupId=maven
> >  > >-DartifactId=maven-war-plu
> > gin
> > -Dversion=
> > 1.6.2-SNAPSHOT
> >
> > or you can reference it in your project :
> > in your project.xml :
> > 
> > maven
> > maven-war-plugin
> > 1.6.2-SNAPSHOT
> > plugin
> > 
> > in your project.properties:
> > maven.repo.remote=http:www.ibiblio.org/maven,
> > http://cvs.apache.org/repository/
> >
> > Arnaud
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >


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

[a4] Build makes Continnum freeze

[Yann Le Du]

Hi,

Thank you for the alpha-4, it is more complete and the Schedules feature seems
like a killer one !

Though, I'm still the same kind of problems as with alpha-3 (precision, I am
using Red Hat Linux). The scenario is :
* the schedule launches a build
* the project is correctly checked-out
* nothing more happens
* when I type an Enter in the Unix console, I get a :
[1]+  Stopped /devel/continuum/continuum/bin/plexus.sh

The last words of the log are :

1863652 [Thread-0] INFO 
org.codehaus.plexus.action.Action:update-project-from-working-directory  -
Updating project 'Common ATLAS connector' from checkout.
1865216 [Thread-0] WARN 
org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2  -
Executable '/devel/maven/maven/bin/m2'.
1865216 [Thread-0] INFO 
org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2  -
Arguments: --batch-mode --non-recursive clean:clean site:site site:deploy
install
1865216 [Thread-0] INFO 
org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2  - Working
directory: /devef/continuum/working/1

Any idea ?

Yann






___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: [m2] reasons for sticking with maven

[Wendell Beckwith]

John is basically stating the very thing that I'm against in the statement
below. I have a 3rd party command line utility from
www.agitar.com,
that basically does unit tests against our code. I want to write (and have
started writing) an M2 plugin to execute the java command line for the
agitation process from my plugin. All I need now to complete my plugin
besides more hours in a day is a plugin that will allow me to execute a java
command line. Now my plugin will integrate with the maven lifecycle during
the test phase. However, first I'm told to use the maven-execute-plugin and
then another dev states that it's bad and wants to see it eliminated, I'm
left thinking WTF!? This *helps* me adopt maven and the process, not hinders
it. My whole purpose for writing the plugin was so that I could make the
plugin once and the other groups here and else where since I would open
source it would be able to reuse it. Is this not what maven is for?

Wb


On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1


[Snipped]

|
> | 3. Need to do a myriad of simple things such as automatically run java
> | command or deploy to tomcat. I used to do this all the time in my ant
> | scripts, ie run my build.xml script and at the end it would run my app
> | on completion. It's a credit to those on this list who reply with ideas
> | and workarounds - however this is kind of related to 2 above, where
> | there are lots of ant tasks out there that are tested to death and that
> | I should be able to use today.
>
> The funny thing about Maven 2 is that it facilitates external plugin
> development. You can load a plugin from a repository hosted anywhere.
> Personally, I feel strongly that executing random commands from within
> the build process is a Bad Thing, and a thing that is bad and common
> with Ant. Maven - and also Ant, to a lesser extent - is a build tool.
> It's not a launching platform, and it's not a tool to be used to run
> your coffee maker. Executing random commands from a configuration in a
> POM is:
>
> a. unscaleable, since that runtime config is not encapsulated for reuse
>
> b. bound to partition your build logic into multiple pieces, which now
> have to be maintained from multiple sources.
>
> In Ant, you can do anything you please, including things that don't
> relate to the process of building software. It's important to keep a
> clear idea of the problem domain we're trying to address here.
>
> Having said that, there's nothing stopping you from hosting your own
> maven-foo-plugin on Sourceforge or somesuch. If you find what you
> perceive to be a hole in our plugin offering, and cannot convince us to
> fill it, there's nothing stopping you from scratching your own itch. We
> currently have maven-execute-plugin on the mojos project, but I'd really
> like to see it deprecated and eliminated eventually.
>
>

Re: [m2] reasons for sticking with maven

[Ashley Williams]

I appreciate your response and I hope this information is useful to  
others as well
as myself. With regards to comparing Ivy to Maven you might be right  
in saying it's
comparing apples to oranges. Nevertheless it sure doesn't look that  
way to the

newbie and I would say that you've made that
comparison - which would interest lots of people. Maybe its worth  
putting

it up on your website as the Ivy guys have done.

http://www.jayasoft.fr/org/modules/ivy/comparison.php

Maybe also a fleshed out roadmap would help with info that currently  
only exists on this

mailing list.

With both Ant and Maven out there, I believe that Maven needs more of  
a sales pitch
to compete for eyeballs - although I realize this would be low on  
your list.


Thanks
-AW

On 20 Sep 2005, at 16:49, Jason van Zyl wrote:


On Tue, 2005-09-20 at 14:19 +0100, Ashley Williams wrote:



1. Usability from Ant - there are hundreds of Ant targets out there
that are useful for me today. I can't justify waiting for them to be
rewritten as Maven equivalents not only because I need functionality
today, but also because I don't see why I have to abandon my
experience with ant.



We are rapidly trying to make Ant functionality available in m2 by
creating a plugin type that allows you to script up plugins using  
Ant's

familiar XML scripting. If you can't wait and have a pending project
then your stance is understandable.

For the time being you can take advantage of what we've made available
via Ant tasks.



2. Usability from Eclipse - when will I be able to ditch the command
line and create and manage projects entirely from eclipse



This is something that is actively being pursued and something will
materialize sooner rather then later. We understand the critical  
nature

of tool integration. The importance is not lost on us, we understand.



3. Need to do a myriad of simple things such as automatically run
java command or deploy to tomcat. I used to do this all the time in
my ant scripts, ie run my build.xml script and at the end it would
run my app on completion. It's a credit to those on this list who
reply with ideas and workarounds - however this is kind of related to
2 above, where there are lots of ant tasks out there that are tested
to death and that I should be able to use today.



Here our aims are different. We don't want everyone scripting up
everything in their own way. It may be convenient in the short term  
but
we would prefer to wait for someone to create a coherent,  
consistent way
to launch an appserver for testing so that it benefits all Maven  
users.

We feel in the long run this approach serves the community better but
this notion is often at odds with folks who needs to get things done
Right Now(tm).



4. Online documentation. Simple example was trying to get the
assembly plugin to work which Daniel Shomer had to look into the
source code to advise me of what to do. This is just one example of
many.



The documentation is admittedly lacking. I am actually working pretty
much full-time on writing doco for the release so this is not lost  
on us
either. We know that documentation is critical for successful  
widespread

adoption.



5. Other project structures. Sometimes I will encounter a project
where all the source code is in one tree (beginning with com/). I'm
not saying its any better than one directory per artifact, but I am
saying I encounter such projects in my career and as such I know I
wouldn't be able to use maven.



That's a choice you'll have to make. Many people have found making the
switch to our default ways of doing things has numerous benefits. If
it's not something you can do then we understand but we feel  
coherency,
consistency, and comprehension win out over other concerns. Make a  
good

plugin and all Maven users benefit. Make a one off script for your own
setup and you've just isolated yourself from a great source of  
potential
help. Making a decent plugin might take you an extra 20% in time  
but the
ultimate savings in time has shown itself in our community over and  
over

again.

We also know that new projects are starting all the time and this  
is the

ideal time to try Maven. For people who have different structures, you
will probably also find that their build now works and in these  
cases I

would never recommend switching from Make or Ant unless you are having
serious problems with maintenance.



6. Contribute to the code. I have tried to get a foot in the door in
order to fix some of my own critisisms, but the lack of javadocs mean
that I really can't do this other than for some simple plugins. That
is unless I had lots of time to spare which I don't. In turn that
makes me concerned how the project will attract other developers to
move things along quickly.



We have actually attracted more developers in the last 6 months then
ever before. We've got 4-5 new developers on the maven project and at
least as many on the Mojo project. So things are actually looking  

Re: [m2] reasons for sticking with maven

[Ashley Williams]

On 20 Sep 2005, at 16:15, John Casey wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Comments are inline. Please bear with me, I think my responses are as
lengthy as your original email! :(

Cheers,

John

Ashley Williams wrote:
| Sincere apologies to the dev team if this email seems like a  
troll, I

| absolutely don't mean it to be. I'm aware that they continue to do
| outstanding work and are few in number.
|
| The more I use Maven the more I get a feel for the size and shape  
of  it
| and find myself looking for features that aren't there. Since I   
joined
| the community I've posted questions on what I consider to be  the  
most

| important aspects of a build system namely (yes in this order):
|
| 1. Usability from Ant - there are hundreds of Ant targets out there
| that are useful for me today. I can't justify waiting for them to be
| rewritten as Maven equivalents not only because I need functionality
| today, but also because I don't see why I have to abandon my   
experience

| with ant.

I've already addressed this with you and others on this list. I've
mentioned that I'm fully in favor of this sort of integration, and I
have some starting points from Chris that I'll be putting in to allow
this sort of thing. You don't have to wait for all of Ant's API to be
replicated; you only have to wait for me to get this one change in  
place. :)




I'm extremely pleased to hear this. I meet all sorts on this list and  
I don't know
which contributors are most responsible for steering the project or  
are just

giving there opinion on what they would like to happen. Maybe the
roadmap could be maintained a little to show which suggestions have  
actually

been taken on board.


|
| 2. Usability from Eclipse - when will I be able to ditch the command
| line and create and manage projects entirely from eclipse

This depends on people with Eclipse development experience (not
experience using Eclipse) picking up the task and running with it.  
We're
trying to get something together in the way of a more concerted  
effort,
but I'm sure you'll agree that getting a stable API was the first  
thing

to do, since otherwise the Eclipse integration project would have to
track a moving target. Now that we've got a beta-1 release, we can  
start

thinking about this.

|
| 3. Need to do a myriad of simple things such as automatically  
run  java
| command or deploy to tomcat. I used to do this all the time in   
my ant
| scripts, ie run my build.xml script and at the end it would  run  
my app
| on completion. It's a credit to those on this list who  reply  
with ideas

| and workarounds - however this is kind of related to  2 above, where
| there are lots of ant tasks out there that are tested  to death  
and that

| I should be able to use today.

The funny thing about Maven 2 is that it facilitates external plugin
development. You can load a plugin from a repository hosted anywhere.
Personally, I feel strongly that executing random commands from within
the build process is a Bad Thing,


I can already do that with a mojo - I can write any old java and  
attach it
to any old lifecycle phase. BUT I would love to get up to that same  
mischief

using the language/syntax of Ant rather than Java!


and a thing that is bad and common
with Ant. Maven - and also Ant, to a lesser extent - is a build tool.
It's not a launching platform, and it's not a tool to be used to run
your coffee maker. Executing random commands from a configuration in a
POM is:

a. unscaleable, since that runtime config is not encapsulated for  
reuse


b. bound to partition your build logic into multiple pieces, which now
have to be maintained from multiple sources.

In Ant, you can do anything you please, including things that don't
relate to the process of building software. It's important to keep a
clear idea of the problem domain we're trying to address here.
Having said that, there's nothing stopping you from hosting your own
maven-foo-plugin on Sourceforge or somesuch. If you find what you
perceive to be a hole in our plugin offering, and cannot convince  
us to
fill it, there's nothing stopping you from scratching your own  
itch. We
currently have maven-execute-plugin on the mojos project, but I'd  
really

like to see it deprecated and eliminated eventually.

|
| 4. Online documentation. Simple example was trying to get the   
assembly
| plugin to work which Daniel Shomer had to look into the  source  
code to

| advise me of what to do. This is just one example of  many.

You're not the first to point this out, and properly so. Just this  
week,

one of the devs started fulltime on fixing this. Documentation has
lagged for a few reasons, which I don't offer as excuses. First, the
devs have been trying to stabilize the featureset and functionality
before we try to document it. This is sort of a chicken-egg scenario,
because (as was pointed out) its easier to maintain a clear design
between multiple devs when you have documentation,

RE : [ANN] Continuum 1.0 Alpha 4 Released

[Olivier Lamy]

Hi all,
I have a trouble with the cvs password which is apparently needed ??
I have a scm url : 
scm:cvs:pserver:[EMAIL PROTECTED]:/local/cvs/Repository:module.
 
The password associated to anoncvs is an empty password.
The output generated is : 
 
Exception:Cannot checkout sources.Exception while executing SCM
command.password is required
This configuration worked with alpha-3.
Do I need to configure empty password somewhere ?
Thanks,
Olivier
 

-Message d'origine-
De : Emmanuel Venisse [mailto:[EMAIL PROTECTED] 
Envoyé : mardi 20 septembre 2005 16:57
À : dev@maven.apache.org; users@maven.apache.org;
continuum-users@maven.apache.org; announce@apache.org
Objet : [ANN] Continuum 1.0 Alpha 4 Released



The Maven team is pleased to announce the 1.0-alpha-4 release of 
Continuum. This release offers users both an advance look at what's in 
Continuum 1.0 and a head start in helping to shape the final Continuum 
release. 

You can find everything here: 

http://maven.apache.org/continuum 

The binaries can be found here: 

http://maven.apache.org/continuum/download.html 

Among the improvements, we have now: 
  - Schedule support, each project can use its own schedule 
  - Build definitions, each project can run multiple build whith
different 
options/goals/profiles 
  - Added a jabber notifier 
  - Added a msn notifier 

The change log can be found here: 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540
 &styleName=Html&version=11665 

Emmanuel 


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



This e-mail, any attachments and the information contained therein ("this 
message") are confidential and intended solely for the use of the addressee(s). 
If you have received this message in error please send it back to the sender 
and delete it. Unauthorized publication, use, dissemination or disclosure of 
this message, either in whole or in part is strictly prohibited.
--
Ce message électronique et tous les fichiers joints ainsi que  les informations 
contenues dans ce message ( ci après "le message" ), sont confidentiels et 
destinés exclusivement à l'usage de la  personne à laquelle ils sont adressés. 
Si vous avez reçu ce message par erreur, merci  de le renvoyer à son émetteur 
et de le détruire. Toutes diffusion, publication, totale ou partielle ou 
divulgation sous quelque forme que se soit non expressément autorisées de ce 
message, sont interdites.
-

Re: ejb and war plugins (maven 1.1 beta2)

[Arnaud HERITIER]

He should add a requirement for the war plugin.
I'll see with him..

Arnaud

On 9/20/05, jan_bar <[EMAIL PROTECTED]> wrote:
> 
> Thanks for your time Arnaud, it works for me. Vincent should fix code for
> http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html?page=4
> 
> Jan
> 
> "Arnaud HERITIER" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> I published a snapshot
> you can install it locally
> maven plugin:download
> -Dmaven.repo.remote=http:www.ibiblio.org/maven,
> http://cvs.apache.org/reposit
> ory/
> -DgroupId=maven
>  >-DartifactId=maven-war-plu
> gin
> -Dversion=
> 1.6.2-SNAPSHOT
> 
> or you can reference it in your project :
> in your project.xml :
> 
> maven
> maven-war-plugin
> 1.6.2-SNAPSHOT
> plugin
> 
> in your project.properties:
> maven.repo.remote=http:www.ibiblio.org/maven,
> http://cvs.apache.org/repository/
> 
> Arnaud
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: ejb and war plugins (maven 1.1 beta2)

[jan_bar]

Thanks for your time Arnaud, it works for me. Vincent should fix code for
http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html?page=4

Jan

"Arnaud HERITIER" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
I published a snapshot
you can install it locally
maven plugin:download
-Dmaven.repo.remote=http:www.ibiblio.org/maven,http://cvs.apache.org/reposit
ory/
-DgroupId=maven
-DartifactId=maven-war-plu
gin
-Dversion=
1.6.2-SNAPSHOT

or you can reference it in your project :
in your project.xml :

maven
maven-war-plugin
 1.6.2-SNAPSHOT
plugin

in your project.properties:
maven.repo.remote=http:www.ibiblio.org/maven,
http://cvs.apache.org/repository/

Arnaud





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

RE: [m2] reasons for sticking with maven

[Dave Neuer]

John, I appreciate your thoughful and reasonable responses to
questions/issues like this. I have to second Ashley on this one. Please
try not to take the following personally, but consider it one person's
bad experience w/ trying to use m2 to do what seems like a simple
thing...

I really like being able to do "m2 clean:clean compile test install."

However, I don't like having no ability to reuse test code from one
project in another project which depends on it. Example: project A has
interface Blah and interface BlahDAO to persist blahs. I have
AbstractBlahDAOTest which has testXXX methods which test *interface
invariant* conditions of BlahDAO. Project B has a new subclass of Blah
and BlahDAO, but it's ProjectBBlahDAO *must* still abide by the
interface invariant constraints. So I want to have ProjectBBlahDAOTest
which extends AbstractBlahDAOTest from project A, but I can't because I
can't generate another (test) artifact in maven.

So, I spent between 3 days and a week reading the source and the (mostly
absent) documentation for plugin development, and developed
maven-test-artfiact plugin. Finally got it to generate the
${artifactId}-test.jar AND install it, but it turns out surefire won't
run tests where some of the testXXX methods are in an abstract base
class in another jar, apparently (even though it loads the class).

To which I have to say: why the hell did someone develop surefire in the
first place? There's already a perfectly good Ant junit task? And why
their own microcontainer? What the heck was wrong w/ Spring (which lots
of people already use).

It seems to me to be a codehaus thing: a propensity to eschew reuse of
other people's code.

So, the upshot is, my plugin doesn't work. It wouldn't work outside of
m2 anyway (since m2 plugins don't rely on normal Java mechanisms -- like
setter injection, to set their properties) so it's not really general as
I've heard claimed by some here as an argument why maven plugins are
good - loosely coupled to maven. And to make it work, I might have to
hack surefire. And plexus. And whatever other 20 wheels have been
reinvented rather than reused.

I realise that some of the above may be perceived as somewhat
inflammatory, but it's really just born out of the frustration of seeing
what seems like it should be an easy task -- one which I *can't imagine*
I'm the only one requiring -- be so difficult.

And since I don't really have more time to steal from my project to
devote to the maven plugin development task, I'm left looking for
alternatives, or reluctantly planning to rewrite the build process in
Ant buildfiles in the not too distant future.

Respectfully but w/ frustration and confusion,
Dave

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

Re: [m2] reasons for sticking with maven

[Jason van Zyl]

On Tue, 2005-09-20 at 14:19 +0100, Ashley Williams wrote:

> 1. Usability from Ant - there are hundreds of Ant targets out there  
> that are useful for me today. I can't justify waiting for them to be  
> rewritten as Maven equivalents not only because I need functionality  
> today, but also because I don't see why I have to abandon my  
> experience with ant.

We are rapidly trying to make Ant functionality available in m2 by
creating a plugin type that allows you to script up plugins using Ant's
familiar XML scripting. If you can't wait and have a pending project
then your stance is understandable. 

For the time being you can take advantage of what we've made available
via Ant tasks.

> 2. Usability from Eclipse - when will I be able to ditch the command  
> line and create and manage projects entirely from eclipse

This is something that is actively being pursued and something will
materialize sooner rather then later. We understand the critical nature
of tool integration. The importance is not lost on us, we understand.

> 3. Need to do a myriad of simple things such as automatically run  
> java command or deploy to tomcat. I used to do this all the time in  
> my ant scripts, ie run my build.xml script and at the end it would  
> run my app on completion. It's a credit to those on this list who  
> reply with ideas and workarounds - however this is kind of related to  
> 2 above, where there are lots of ant tasks out there that are tested  
> to death and that I should be able to use today.

Here our aims are different. We don't want everyone scripting up
everything in their own way. It may be convenient in the short term but
we would prefer to wait for someone to create a coherent, consistent way
to launch an appserver for testing so that it benefits all Maven users.
We feel in the long run this approach serves the community better but
this notion is often at odds with folks who needs to get things done
Right Now(tm). 

> 4. Online documentation. Simple example was trying to get the  
> assembly plugin to work which Daniel Shomer had to look into the  
> source code to advise me of what to do. This is just one example of  
> many.

The documentation is admittedly lacking. I am actually working pretty
much full-time on writing doco for the release so this is not lost on us
either. We know that documentation is critical for successful widespread
adoption.

> 5. Other project structures. Sometimes I will encounter a project  
> where all the source code is in one tree (beginning with com/). I'm  
> not saying its any better than one directory per artifact, but I am  
> saying I encounter such projects in my career and as such I know I  
> wouldn't be able to use maven.

That's a choice you'll have to make. Many people have found making the
switch to our default ways of doing things has numerous benefits. If
it's not something you can do then we understand but we feel coherency,
consistency, and comprehension win out over other concerns. Make a good
plugin and all Maven users benefit. Make a one off script for your own
setup and you've just isolated yourself from a great source of potential
help. Making a decent plugin might take you an extra 20% in time but the
ultimate savings in time has shown itself in our community over and over
again. 

We also know that new projects are starting all the time and this is the
ideal time to try Maven. For people who have different structures, you
will probably also find that their build now works and in these cases I
would never recommend switching from Make or Ant unless you are having
serious problems with maintenance.

> 6. Contribute to the code. I have tried to get a foot in the door in  
> order to fix some of my own critisisms, but the lack of javadocs mean  
> that I really can't do this other than for some simple plugins. That  
> is unless I had lots of time to spare which I don't. In turn that  
> makes me concerned how the project will attract other developers to  
> move things along quickly.

We have actually attracted more developers in the last 6 months then
ever before. We've got 4-5 new developers on the maven project and at
least as many on the Mojo project. So things are actually looking great
in terms of community involvement and I think it's only going to grow as
we approach a final release. There is currently a barrier to entry but
we've managed to overcome that and we're working on making getting
involved easier:

http://maven.apache.org/maven2/developers/development-guide.html

> I realize there may be workarounds for some of the above, but I  
> couldn't stick my neck on the line for a dev team and recommend  
> sharing of eclipse hack scripts etc as a way of working. I'm also  
> putting my selfish hat on and say that I'd like to do the above  
> without defending it - there are a few threads on this list already  
> that deal with the pros and cons.
> 
> ***
> 
> Now I'll turn my attention to Ivy. I'

Re: [m2] assembly plugin + a few instructions

[Ashley Williams]

I was expecting the jars from my dependencies section to be there.
However I did manage to find an example of a descriptor file by  
greping in the maven source -

it's under maven-assembly-plugin/

For anyone who's interested
I'm actually trying to see if there is enough in Maven to allow me to  
cobble together an application,
including Class-path entries in manfest, and there is just about.  
Here's what I did:


I added the following to my pom so that my manifest would be  
generated correctly and that

the assembly plugin would find my descriptor:


  
org.apache.maven.plugins
maven-assembly-plugin

  app.xml

  
  
org.apache.maven.plugins
maven-jar-plugin

  

  com.example.mbeans.Main
  true

  

  


then I created the following descriptor app.xml:


  bin
  
tar.gz
tar.bz2
zip
  
  

  target
  
  
*.jar
  

  
  

  /
  runtime

  


Which resulted in a compressed file(s) containing my jar file and its  
dependencies.

I was then able to uncompress it and launch with the java -jar command.

Cheers
AW

On 20 Sep 2005, at 16:21, Daniel Schömer wrote:



Ashley Williams wrote:



On 20 Sep 2005, at 12:49, Daniel Schömer wrote:



Ashley Williams wrote:


Does anyone know how to use assembly:assembly, in particular  
what the

descriptor is supposed to be? I did hardcode it as a path to my pom
from within my pom (that seems wrong) which made the plugin run
without errors, but I didn't see any output file.



I've successfully run assembly:assembly setting descriptorId to  
one of

the id in the provided assemblies ("bin", "src" or
"jar-with-dependencies").




Thanks that worked although I didn't find what I was hoping for in
the resulting zip file.




Hm, I don't know what you expected in the resulting zip file, but
the results I've gotten were as I've expected.

The assemblies shipped with the assembly plugin are relatively
simple xml files specifying file-sets of what to include.  Since
you know ant (as you wrote in
<[EMAIL PROTECTED]>), you can probably
adapt the assembly xml files to your needs.

Regards,
Daniel Schömer


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







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

RE: [m2-b1] POM Inheritance and Variables

[David Pick]

John,

Many Thanks, that did the trick.

Cheers
Dave

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] 
Sent: 20 September 2005 16:22
To: Maven Users List
Subject: Re: [m2-b1] POM Inheritance and Variables

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

System vars are accessed implicitly in m2...try:


~  ${build.debug}
~  ${build.jdk}
~  ${build.jdk}


Cheers,

john

David Pick wrote:
| Hi,
|
| I have the following section in a parent POM:
|
| 
|   
|   
|   org.apache.maven.plugins
|   maven-compiler-plugin
|   
|   
${systemScope.getProperty('build.debug')}
|   
${systemScope.getProperty('build.jdk')}
|   
${systemScope.getProperty('build.jdk')}
|   
|   
|   
| 
|
|
| When I run a Maven build on the child POM the system scope variables
appear to have no effect.
| If I replace them with fixed values then everything works.
|
| The system variables are set when invoking Maven using -D option.
|
| What have I done wrong?
|
| Does the fact that this inherited have any bearing on the property
evaluation?
|
| Many Thanks
| Dave
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMCksK3h2CZwO/4URAnjtAKCR9xO/PWerEM72jUXyapJpax04KQCfQfzR
dpkEVBR7Dwp/SaWGrB55M4w=
=L4D+
-END PGP SIGNATURE-

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


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

Re: [m2-b1] POM Inheritance and Variables

[Trygve Laugstøl]

On Tue, 2005-09-20 at 16:07 +0100, David Pick wrote:
> Hi,
> 
> I have the following section in a parent POM:
> 
> 
>   
>   
>   org.apache.maven.plugins
>   maven-compiler-plugin
> 
>   
> ${systemScope.getProperty('build.debug')}
>   
> ${systemScope.getProperty('build.jdk')}
>   
> ${systemScope.getProperty('build.jdk')}
>   
>   
>   
> 

Using ${build.jdk} with -Dbuild.jdk=1.5 on the command line should work.

--
Trygve


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

Re: [m2] assembly plugin

[Daniel Schömer]

Ashley Williams wrote:
> On 20 Sep 2005, at 12:49, Daniel Schömer wrote:
>> Ashley Williams wrote:
>>> Does anyone know how to use assembly:assembly, in particular what the
>>> descriptor is supposed to be? I did hardcode it as a path to my pom
>>> from within my pom (that seems wrong) which made the plugin run
>>> without errors, but I didn't see any output file.
>>>
>> I've successfully run assembly:assembly setting descriptorId to one of
>> the id in the provided assemblies ("bin", "src" or
>> "jar-with-dependencies").
>
> Thanks that worked although I didn't find what I was hoping for in  
> the resulting zip file.

Hm, I don't know what you expected in the resulting zip file, but
the results I've gotten were as I've expected.

The assemblies shipped with the assembly plugin are relatively
simple xml files specifying file-sets of what to include.  Since
you know ant (as you wrote in
<[EMAIL PROTECTED]>), you can probably
adapt the assembly xml files to your needs.

Regards,
Daniel Schömer


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

Re: [m2-b1] POM Inheritance and Variables

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

System vars are accessed implicitly in m2...try:


~  ${build.debug}
~  ${build.jdk}
~  ${build.jdk}


Cheers,

john

David Pick wrote:
| Hi,
|
| I have the following section in a parent POM:
|
| 
|   
|   
|   org.apache.maven.plugins
|   maven-compiler-plugin
|   
|   
${systemScope.getProperty('build.debug')}
|   
${systemScope.getProperty('build.jdk')}
|   
${systemScope.getProperty('build.jdk')}
|   
|   
|   
| 
|
|
| When I run a Maven build on the child POM the system scope variables
appear to have no effect.
| If I replace them with fixed values then everything works.
|
| The system variables are set when invoking Maven using -D option.
|
| What have I done wrong?
|
| Does the fact that this inherited have any bearing on the property
evaluation?
|
| Many Thanks
| Dave
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMCksK3h2CZwO/4URAnjtAKCR9xO/PWerEM72jUXyapJpax04KQCfQfzR
dpkEVBR7Dwp/SaWGrB55M4w=
=L4D+
-END PGP SIGNATURE-

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

Re: ejb and war plugins (maven 1.1 beta2)

[Arnaud HERITIER]

I published a snapshot
you can install it locally
maven plugin:download
-Dmaven.repo.remote=http:www.ibiblio.org/maven,http://cvs.apache.org/repository/
-DgroupId=maven
-DartifactId=maven-war-plugin
-Dversion=
1.6.2-SNAPSHOT

or you can reference it in your project :
in your project.xml :

maven
maven-war-plugin
 1.6.2-SNAPSHOT
plugin

in your project.properties:
maven.repo.remote=http:www.ibiblio.org/maven,
http://cvs.apache.org/repository/

Arnaud

On 9/20/05, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
> 
> I opened on Jira a release 1.6.2
> So we're working on the 1.6.2-SNAPSHOT
> The name of the patch isn't important
> 
> Arnaud
> 
> On 9/20/05, jan_bar <[EMAIL PROTECTED]> wrote:
> > 
> > Thanks Arnaud,
> > 
> > one more question: If I want to create my patch, which version of the 
> > plugin
> > should I use so it will not conflict with war plugin patch once 
> > published?
> > WAR plugin is now 1.6.1, can I name it 1.6.1-patch ? I think that there
> > should be only number on the version, so 1.6.1.1  would 
> > be better?
> > 
> > Jan
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED] 
> > 
> > 
>

Re: [m2] reasons for sticking with maven

[John Casey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Comments are inline. Please bear with me, I think my responses are as
lengthy as your original email! :(

Cheers,

John

Ashley Williams wrote:
| Sincere apologies to the dev team if this email seems like a troll, I
| absolutely don't mean it to be. I'm aware that they continue to do
| outstanding work and are few in number.
|
| The more I use Maven the more I get a feel for the size and shape of  it
| and find myself looking for features that aren't there. Since I  joined
| the community I've posted questions on what I consider to be  the most
| important aspects of a build system namely (yes in this order):
|
| 1. Usability from Ant - there are hundreds of Ant targets out there
| that are useful for me today. I can't justify waiting for them to be
| rewritten as Maven equivalents not only because I need functionality
| today, but also because I don't see why I have to abandon my  experience
| with ant.

I've already addressed this with you and others on this list. I've
mentioned that I'm fully in favor of this sort of integration, and I
have some starting points from Chris that I'll be putting in to allow
this sort of thing. You don't have to wait for all of Ant's API to be
replicated; you only have to wait for me to get this one change in place. :)

|
| 2. Usability from Eclipse - when will I be able to ditch the command
| line and create and manage projects entirely from eclipse

This depends on people with Eclipse development experience (not
experience using Eclipse) picking up the task and running with it. We're
trying to get something together in the way of a more concerted effort,
but I'm sure you'll agree that getting a stable API was the first thing
to do, since otherwise the Eclipse integration project would have to
track a moving target. Now that we've got a beta-1 release, we can start
thinking about this.

|
| 3. Need to do a myriad of simple things such as automatically run  java
| command or deploy to tomcat. I used to do this all the time in  my ant
| scripts, ie run my build.xml script and at the end it would  run my app
| on completion. It's a credit to those on this list who  reply with ideas
| and workarounds - however this is kind of related to  2 above, where
| there are lots of ant tasks out there that are tested  to death and that
| I should be able to use today.

The funny thing about Maven 2 is that it facilitates external plugin
development. You can load a plugin from a repository hosted anywhere.
Personally, I feel strongly that executing random commands from within
the build process is a Bad Thing, and a thing that is bad and common
with Ant. Maven - and also Ant, to a lesser extent - is a build tool.
It's not a launching platform, and it's not a tool to be used to run
your coffee maker. Executing random commands from a configuration in a
POM is:

a. unscaleable, since that runtime config is not encapsulated for reuse

b. bound to partition your build logic into multiple pieces, which now
have to be maintained from multiple sources.

In Ant, you can do anything you please, including things that don't
relate to the process of building software. It's important to keep a
clear idea of the problem domain we're trying to address here.

Having said that, there's nothing stopping you from hosting your own
maven-foo-plugin on Sourceforge or somesuch. If you find what you
perceive to be a hole in our plugin offering, and cannot convince us to
fill it, there's nothing stopping you from scratching your own itch. We
currently have maven-execute-plugin on the mojos project, but I'd really
like to see it deprecated and eliminated eventually.

|
| 4. Online documentation. Simple example was trying to get the  assembly
| plugin to work which Daniel Shomer had to look into the  source code to
| advise me of what to do. This is just one example of  many.

You're not the first to point this out, and properly so. Just this week,
one of the devs started fulltime on fixing this. Documentation has
lagged for a few reasons, which I don't offer as excuses. First, the
devs have been trying to stabilize the featureset and functionality
before we try to document it. This is sort of a chicken-egg scenario,
because (as was pointed out) its easier to maintain a clear design
between multiple devs when you have documentation, but documentation of
an evolving API gets stale quickly.

Now that you've read the source code for the assembly plugin, will you
contribute some documentation?

|
| 5. Other project structures. Sometimes I will encounter a project  where
| all the source code is in one tree (beginning with com/). I'm  not
| saying its any better than one directory per artifact, but I am  saying
| I encounter such projects in my career and as such I know I  wouldn't be
| able to use maven.

This project can get a little preachy, and I'm no exception. We tend to
believe that we've seen a lot of use cases (many on this list), and that
our standard layout is th

[m2-b1] POM Inheritance and Variables

[David Pick]

Hi,

I have the following section in a parent POM:




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

${systemScope.getProperty('build.debug')}

${systemScope.getProperty('build.jdk')}

${systemScope.getProperty('build.jdk')}






When I run a Maven build on the child POM the system scope variables appear to 
have no effect.
If I replace them with fixed values then everything works.

The system variables are set when invoking Maven using -D option.

What have I done wrong?

Does the fact that this inherited have any bearing on the property evaluation?

Many Thanks
Dave

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

[ANN] Continuum 1.0 Alpha 4 Released

[Emmanuel Venisse]

The Maven team is pleased to announce the 1.0-alpha-4 release of
Continuum. This release offers users both an advance look at what's in
Continuum 1.0 and a head start in helping to shape the final Continuum
release.

You can find everything here:

http://maven.apache.org/continuum

The binaries can be found here:

http://maven.apache.org/continuum/download.html

Among the improvements, we have now:
 - Schedule support, each project can use its own schedule
 - Build definitions, each project can run multiple build whith different 
options/goals/profiles

 - Added a jabber notifier
 - Added a msn notifier

The change log can be found here: 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540&styleName=Html&version=11665


Emmanuel


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

Re: Fw :[m2-beta-1] Ear plugin: root-context & copied JARs/WARs

[Kenney Westerhof]

On Tue, 20 Sep 2005 [EMAIL PROTECTED] wrote:

Hi,


> Nobody has an answer for these 2 little questions?

Sorry but I missed this one!

>
> For the second question, I've struggled with scopes, but it seems that
> because of the transitive dependencies feature, the Ear plugin packages
> every Jar set to compile/runtime in the pom of the War...

See below.

> Fabrice.
>
> -
>
> Hi guys!
>
> I've 2 little questions about the Ear plugin (version 2.0beta1):
>
> 1- how can I tell the Ear plugin to use a specific root-context for a War
> when it generates the application.xml? (instead of using the artifactId)
> Something like the "" in m1.

Use the plugin configuration. You can specify configuration options for
the modules:

  

  /yourContextRoot/
  the_web_uri 

  

Maybe Stephane Nicoll can confirm if this is correct?

I personally use xdoclet and j2ee specific descriptor files within the
WEB-INF directory of the war itself, because you can specify the
location there too, and it'll work even if you deploy the war standalone.
On the other hand, for ears, it's best to use application.xml.

> 2- when the plugin generates the Ear, it packages most dependencies of the
> War module, while they already exist the the WEB-INF/lib of the War (and I
> don't want them to be copied a second time at the root of the Ear). Those
> dependencies have a "compile" scope in the pom of the War module. Is it the
> normal behaviour? Is there a property or something to tell m2 not to
> package them?

Well this is a bit of a problem.
You can specify the dependencies in the war pom with scope 'provided',
so they won't end up in the war.
This works great if you always use the war within an ear that also has
those dependencies, but if you use that war standalone it'll break.
Also, those war dependencies are not transferred to the ear project,
so you have to respecify them there.

>
> Thanks for your help!

Sorry we missed this!

-- Kenney

> Cheers,
> Fabrice.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

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

Re: ejb and war plugins (maven 1.1 beta2)

[Arnaud HERITIER]

I opened on Jira a release 1.6.2
So we're working on the 1.6.2-SNAPSHOT
The name of the patch isn't important

Arnaud

On 9/20/05, jan_bar <[EMAIL PROTECTED]> wrote:
> 
> Thanks Arnaud,
> 
> one more question: If I want to create my patch, which version of the 
> plugin
> should I use so it will not conflict with war plugin patch once published?
> WAR plugin is now 1.6.1, can I name it 1.6.1-patch? I think that there
> should be only number on the version, so 1.6.1.1  would be 
> better?
> 
> Jan
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: [m2] assembly plugin

[Ashley Williams]

Thanks that worked although I didn't find what I was hoping for in  
the resulting zip file.


On 20 Sep 2005, at 12:49, Daniel Schömer wrote:


Hi.

Ashley Williams wrote:


Does anyone know how to use assembly:assembly, in particular what the
descriptor is supposed to be? I did hardcode it as a path to my pom
from within my pom (that seems wrong) which made the plugin run
without errors, but I didn't see any output file.



As far as I could examine the source of the assembly plugin, the
descriptor is a xml file that contains a description of what to
asseble.  The "descriptor" property is a path to such a file and
descriptorId is the id of a descriptor that is known to the assembly
plugin.

Is seems the assembly descriptors currently provided by the  
assembly plugin

are there:

  http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven- 
plugins/maven-assembly-plugin/src/main/resources/assemblies/


I've successfully run assembly:assembly setting descriptorId to one of
the id in the provided assemblies ("bin", "src" or
"jar-with-dependencies").



Regards,
Daniel Schömer


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





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

[m2] reasons for sticking with maven

[Ashley Williams]

Sincere apologies to the dev team if this email seems like a troll, I  
absolutely don't mean it to be. I'm aware that they continue to do  
outstanding work and are few in number.


The more I use Maven the more I get a feel for the size and shape of  
it and find myself looking for features that aren't there. Since I  
joined the community I've posted questions on what I consider to be  
the most important aspects of a build system namely (yes in this order):


1. Usability from Ant - there are hundreds of Ant targets out there  
that are useful for me today. I can't justify waiting for them to be  
rewritten as Maven equivalents not only because I need functionality  
today, but also because I don't see why I have to abandon my  
experience with ant.


2. Usability from Eclipse - when will I be able to ditch the command  
line and create and manage projects entirely from eclipse


3. Need to do a myriad of simple things such as automatically run  
java command or deploy to tomcat. I used to do this all the time in  
my ant scripts, ie run my build.xml script and at the end it would  
run my app on completion. It's a credit to those on this list who  
reply with ideas and workarounds - however this is kind of related to  
2 above, where there are lots of ant tasks out there that are tested  
to death and that I should be able to use today.


4. Online documentation. Simple example was trying to get the  
assembly plugin to work which Daniel Shomer had to look into the  
source code to advise me of what to do. This is just one example of  
many.


5. Other project structures. Sometimes I will encounter a project  
where all the source code is in one tree (beginning with com/). I'm  
not saying its any better than one directory per artifact, but I am  
saying I encounter such projects in my career and as such I know I  
wouldn't be able to use maven.


6. Contribute to the code. I have tried to get a foot in the door in  
order to fix some of my own critisisms, but the lack of javadocs mean  
that I really can't do this other than for some simple plugins. That  
is unless I had lots of time to spare which I don't. In turn that  
makes me concerned how the project will attract other developers to  
move things along quickly.


I realize there may be workarounds for some of the above, but I  
couldn't stick my neck on the line for a dev team and recommend  
sharing of eclipse hack scripts etc as a way of working. I'm also  
putting my selfish hat on and say that I'd like to do the above  
without defending it - there are a few threads on this list already  
that deal with the pros and cons.


***

Now I'll turn my attention to Ivy. I've began to look at this product  
and it seems to offer many of the features of Maven including


1. transitive dependencies
2. compatibility with the ibiblio repository

and in addition

1. the online docs are excellent even if they are in broken english
2. Can manage projects from with eclipse, since they are just ant  
projects (with simple projects, haven't tried anything tricky)
3. Can manage maven style module directory structures or single  
source trees. Obviously being Ant, it can manage any structure you  
like, but these are the only two sane ones I know.


Yes there is stuff that it doesn't have such as a built in lifecycle,  
but with what I've learnt from the maven layout, I feel I could quite  
easily replicate that in ant in a reusable way. That said I would  
prefer not to have to. I suppose I'm looking for reassurance as to  
why Maven is the way to go because there seems to be considerable  
overlap with Ivy.




I realize that I am being very selfish here, but I have to think very  
carefully about what I invest my time in. Maven has all the hallmarks  
of being that software that I felt was missing during my career,  
which is why I care enough about it to spare the time for these  
critisisms. I just want to be sure it has a chance of gaining  
critical mass.


Maybe the gatekeeper/guardian of this project needs to write some  
sort of Jerry Maguire style memo that says what Maven's purpose is  
and plans are so that we can all keep focused on that.


Maybe my views aren't representative of a large enough demographic in  
which case this email will just slip away into obscurity, but either  
way thanks for reading and please don't take it as a troll


-AW

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

Re: ejb and war plugins (maven 1.1 beta2)

[jan_bar]

Thanks Arnaud,

one more question: If I want to create my patch, which version of the plugin
should I use so it will not conflict with war plugin patch once published?
WAR plugin is now 1.6.1, can I name it 1.6.1-patch? I think that there
should be only number on the version, so 1.6.1.1 would be better?

Jan




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

Re: SPAM: Problem with authenticated POM URLs

[Mark Hobson]

Hi Emmanuel,

I found the problem deep within plexus, see:

http://jira.codehaus.org/browse/PLX-157

Do you think this will get in for alpha4?

Cheers,

Mark

On 20/09/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> Hi Mark,
>
> authorized urls are http[s]://[username:[EMAIL PROTECTED]/urel/to/pom.xml
>
> I think your url was incorrect because continuum couldn't download it ("The 
> URL you
> provided doesn't exist"). Try to obtain the correct url in your browser and 
> then put it in
> continuum.
>
> Do you have a particular authentication mode on your server?
>
> If it doesn't work, you can upload your pom.
>
> Emmanuel
>
> Mark Hobson wrote:
> > Hi there,
> >
> > I'm having problems with authenticated POM URLs with the build
> > continuum-20050920.033000.tar.gz.  Our SVN repository is accessible
> > via authenticated https and authenticated http internally, so I've
> > been trying the following and get the corresponding errors:
> >
> > https://my.domain/url/to/pom.xml
> > "The URL you provided doesn't exist"
> >
> > https://[EMAIL PROTECTED]/url/to/pom.xml
> > "You must provide a valid url"
> >
> > https://username:[EMAIL PROTECTED]/url/to/pom.xml
> > "The URL you provided doesn't exist"
> >
> > http://my.domain/url/to/pom.xml
> > "The URL you provided doesn't exist"
> >
> > http://[EMAIL PROTECTED]/url/to/pom.xml
> > "You must provide a valid url"
> >
> > http://username:[EMAIL PROTECTED]/url/to/pom.xml
> > "The URL you provided doesn't exist"
> >
> > There are no errors in the logs (aside from the side-issue of:
> >
> > WARN VelocityComponent -
> > org.apache.velocity.runtime.exception.ReferenceException: reference :
> > template = screens/AddMavenProject.vm [line 1,column 16] :
> > $fvr.getElementResult( $element.getId() ).errorMessage is not a valid
> > reference.
> >
> > which causes "[ $fvr.getElementResult( $element.getId() ).errorMessage
> > ]" to be displayed as the validation message alongside the upload POM
> > field).
> >
> > I see from CONTINUUM-306 that https should be supported - am I doing
> > anything wrong?
> >
> > Cheers,
> >
> > Mark
> >
> >
>
>

Re: [m1.1b1] log4j error

[Arnaud HERITIER]

Not it's not yet resolved :-(
I'll take a look at it.
I'm not sure that an issue was opened.

Arnaud

On 9/20/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
> 
> Is this solved in Maven 1.1 beta 2? Also what is the JIRA issue related to
> this problem?
> 
> 2005/8/25, Arnaud HERITIER <[EMAIL PROTECTED]>:
> >
> > you can safely ignore them
> > we'll try to remove them as soon as possible.
> > an issue is open in velocity
> >
> > Arnaud
> >
> > On 8/25/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
> > >
> > > And is there a fix for it or can I safely ignore those errors?
> > >
> > > 2005/8/25, Arnaud HERITIER <[EMAIL PROTECTED]>:
> > > >
> > > > This is a problem between velocity 1.4 and log4J.
> > > >
> > > > Arnaud
> > > >
> > > > On 8/25/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I get the following error in my build since I upgraded to Maven
> > > 1.1beta1
> > > > .
> > > > > Any idea what might be the problem?
> > > > >
> > > > > log4j:ERROR Attempted to append to closed appender named [null].
> > > > >
> > > > >
> > > > > I get that same line many, many times but the build seems to
> > continue
> > > > > fine.
> > > > >
> > > > > regards,
> > > > >
> > > > > Wim
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> 
>

RE: [m2] trouble accessing internal repository with beta1

[Yann Le Du]

Erratum : the [3] sample is
common-framework/1.0.4-SNAPSHOT/maven-metadata-local.xml, of course.

--- Yann Le Du <[EMAIL PROTECTED]> a écrit :

> Hi,
> 
> I'm also having troubles accessing artifacts from my corp repository. More
> exactly, I can access plain versions (e.g. 1.0.3), but not snapshots (e.g.,
> 1.0.4-SNAPSHOT).
> 
> Here's my conf, which was working well before m2b1 :
> 
> [1] On my corp. repo :
> ~   common-framework
> ~   +-- maven-metadata-local.xml [2]
> ~   +-- 1.0.3
> ~   +-- common-framework-1.0.3.jar
> ~   +-- common-framework-1.0.3.pom
> ~   +-- 1.0.4-SNAPSHOT
> ~   +-- common-framework-1.0.4-SNAPSHOT.jar
> ~   +-- common-framework-1.0.4-SNAPSHOT.pom
> ~   +-- maven-metadata-local.xml [3]
> 
> [2] common-framework/maven-metadata-local.xml :
> ~   
> ~ fr.as.common
> ~ common-framework
> ~ 
> ~   
> ~ 1.0.4-SNAPSHOT
> ~ 1.0.3
> ~   
> ~ 
> ~   
> 
> [3] common-framework/maven-metadata-local.xml :
> ~   
> ~ fr.as.common
> ~ common-framework
> ~ 1.0.4-SNAPSHOT
> ~ 
> ~   
> ~ true
> ~   
> ~ 
> ~   
> 
> [4] In my local settings.xml :
> ~ 
> ~   
> ~ central
> ~ http://ricfiled.as.asd.asf/maven/repository
> ~   
> ~   
> ~ central-plugins
> ~ http://ricfiled.as.asd.asf/maven/repository
> ~   
> ~   
> ~ central-plugins-snapshots
> ~ http://ricfiled.as.asd.asf/maven/repository
> ~   
> ~ 
> ...
> ~ 
> ~   
> ~ 
> ~   
> ~ central
> ~ http://ricfiled.as.asd.asf/maven/repository
> ~ always
> ~   
> ~ 
> ~ 
> ~   
> ~ central-plugins
> ~ http://ricfiled.as.asd.asf/maven/repository
> ~ always
> ~   
> ~   
> ~ central-plugins-snapshots
> ~ http://ricfiled.as.asd.asf/maven/repository
> ~ always
> ~   
> ~ 
> ~   
> ~ 
> 
> Yann
> 
> 
> --- Ralph Pöllath <[EMAIL PROTECTED]> a écrit :
> 
> > Hi,
> > 
> > since I upgraded to m2 beta 1, I'm having trouble accessing artifacts  
> > in my internal company-wide repository.
> > 
> > m2 -X deploy prints
> > 
> > ...
> > [INFO] [deploy:deploy]
> > [INFO] Retrieving previous build number from internal-repo
> > 
> > and then hangs forever. I assume it's not an authentication problem,  
> > because changing the password in settings.xml fails immediately with  
> > an AuthenticationException.
> > 
> > Any ideas?
> > 
> > Cheers,
> > -Ralph.
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout !
>  Créez votre Yahoo! Mail sur http://mail.yahoo.fr
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 







___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

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

Re: ejb and war plugins (maven 1.1 beta2)

[Arnaud HERITIER]

On 9/20/05, jan_bar <[EMAIL PROTECTED]> wrote:
> 
> http://jira.codehaus.org/browse/MPWAR-50.
> 
> I am starting with maven and j2ee, so my opinion may be of small value. 
> For
> now I added:
> 
> 
> 


It's good.

Thanks, Jan
> 
> PS: Can I create dependency on plugin patch? Or at least check if the 
> plugin
> is of certain version and issue bug during build? The problem is that the
> dependency is silently skipped.


You can create a dependency on your project to use a GIVEN version of a 
plugin.


statcvs
maven-statcvs-plugin
2.7
plugin
http://statcvs-xml.berlios.de/maven-plugin/


We also created a new tag to check if a minimal version of a plugin is 
available but it will not help you because :
- it's in the plugin-plugin which isn't yet released
- it will move your problem because your build will fail if you don"t have 
at least this new version of the plugin-plugin.
A workaround is to copy the code in your maven.xml :
http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/plugin/plugin.jelly
definition, search for : 



usage : 




Arnaud
Arnaud



"Arnaud HERITIER" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> I never used it but it seems to be a missing feature in the war plugin.
> Can you open an issue. We'll fix it ASAP.
> The behavior of the ejb plugin was certainly changed recently and the war
> plugin wasn't updated.
> We should add the support for types : ejb and ejb-client (generated if
> maven.ejb.client.generate=true) in the war plugin.
> WDYT ?
> 
> Arnaud
> 
> On 9/20/05, jan_bar <[EMAIL PROTECTED]> wrote:
> >
> > No answers so far, but this seems to be basic question for J2EE
> > development
> > with maven. Maybe I was not clear enough.
> >
> > The client code generated for EJB must be included in WAR file. I don't
> > know
> > how to do this with maven 1.1 beta 2 because war plugin copies only
> > type=jar
> > dependencies and EJB client code is type=ejb. Is this bug or I got
> > something
> > wrong?
> >
> > Jan
> >
> > "jan_bar" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > Hi,
> > >
> > > ejb plugin places the EJB client code in repository in ejbs/ > client>.jar.
> > > However the war plugin uses only type=jar dependencies:
> > >
> > > (maven-war-plugin-1.6.1/plugin.jelly, line 149)
> > >
> > > 
> > > 
> > > 
> > >
> > > Seems like bug. How can I add my EJB client jar to WAR?
> > >
> > > Thanks, Jan
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: [m1.1b1] log4j error

[Wim Deblauwe]

Is this solved in Maven 1.1 beta 2? Also what is the JIRA issue related to 
this problem?

2005/8/25, Arnaud HERITIER <[EMAIL PROTECTED]>:
> 
> you can safely ignore them
> we'll try to remove them as soon as possible.
> an issue is open in velocity
> 
> Arnaud
> 
> On 8/25/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
> >
> > And is there a fix for it or can I safely ignore those errors?
> >
> > 2005/8/25, Arnaud HERITIER <[EMAIL PROTECTED]>:
> > >
> > > This is a problem between velocity 1.4 and log4J.
> > >
> > > Arnaud
> > >
> > > On 8/25/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I get the following error in my build since I upgraded to Maven
> > 1.1beta1
> > > .
> > > > Any idea what might be the problem?
> > > >
> > > > log4j:ERROR Attempted to append to closed appender named [null].
> > > >
> > > >
> > > > I get that same line many, many times but the build seems to 
> continue
> > > > fine.
> > > >
> > > > regards,
> > > >
> > > > Wim
> > > >
> > > >
> > >
> > >
> >
> >
> 
>

RE: [m2] trouble accessing internal repository with beta1

[Yann Le Du]

Hi,

I'm also having troubles accessing artifacts from my corp repository. More
exactly, I can access plain versions (e.g. 1.0.3), but not snapshots (e.g.,
1.0.4-SNAPSHOT).

Here's my conf, which was working well before m2b1 :

[1] On my corp. repo :
~   common-framework
~   +-- maven-metadata-local.xml [2]
~   +-- 1.0.3
~   +-- common-framework-1.0.3.jar
~   +-- common-framework-1.0.3.pom
~   +-- 1.0.4-SNAPSHOT
~   +-- common-framework-1.0.4-SNAPSHOT.jar
~   +-- common-framework-1.0.4-SNAPSHOT.pom
~   +-- maven-metadata-local.xml [3]

[2] common-framework/maven-metadata-local.xml :
~   
~ fr.as.common
~ common-framework
~ 
~   
~ 1.0.4-SNAPSHOT
~ 1.0.3
~   
~ 
~   

[3] common-framework/maven-metadata-local.xml :
~   
~ fr.as.common
~ common-framework
~ 1.0.4-SNAPSHOT
~ 
~   
~ true
~   
~ 
~   

[4] In my local settings.xml :
~ 
~   
~ central
~ http://ricfiled.as.asd.asf/maven/repository
~   
~   
~ central-plugins
~ http://ricfiled.as.asd.asf/maven/repository
~   
~   
~ central-plugins-snapshots
~ http://ricfiled.as.asd.asf/maven/repository
~   
~ 
...
~ 
~   
~ 
~   
~ central
~ http://ricfiled.as.asd.asf/maven/repository
~ always
~   
~ 
~ 
~   
~ central-plugins
~ http://ricfiled.as.asd.asf/maven/repository
~ always
~   
~   
~ central-plugins-snapshots
~ http://ricfiled.as.asd.asf/maven/repository
~ always
~   
~ 
~   
~ 

Yann


--- Ralph Pöllath <[EMAIL PROTECTED]> a écrit :

> Hi,
> 
> since I upgraded to m2 beta 1, I'm having trouble accessing artifacts  
> in my internal company-wide repository.
> 
> m2 -X deploy prints
> 
> ...
> [INFO] [deploy:deploy]
> [INFO] Retrieving previous build number from internal-repo
> 
> and then hangs forever. I assume it's not an authentication problem,  
> because changing the password in settings.xml fails immediately with  
> an AuthenticationException.
> 
> Any ideas?
> 
> Cheers,
> -Ralph.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout !
 Créez votre Yahoo! Mail sur http://mail.yahoo.fr

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

[m2] trouble accessing internal repository with beta1

[Ralph Pöllath]

Hi,

since I upgraded to m2 beta 1, I'm having trouble accessing artifacts  
in my internal company-wide repository.


m2 -X deploy prints

...
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from internal-repo

and then hangs forever. I assume it's not an authentication problem,  
because changing the password in settings.xml fails immediately with  
an AuthenticationException.


Any ideas?

Cheers,
-Ralph.




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

RE: additional xml-files in WEB-INF directory

[Filip Polsakiewicz]

Hi,
that was the mistake: my directory was main/src/webapp and the property was
set to src/main/webapp

Thanks Filip

-Original Message-
From: Yann Le Du [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 20, 2005 2:18 PM
To: Maven Users List
Subject: Re: additional xml-files in WEB-INF directory

Success here also with an XML file.

~   ./src/main/webapp/WEB-INF
~   +-- web.xml
~   +-- test.xml

results into :

~   ./target/artifactId-version/WEB-INF
~   +-- web.xml
~   +-- test.xml

Which version of Maven are you using ?

Also, you said you were using "Main / src / webapp", didn't you mean "src /
main / webapp" ?

Yann


--- Jesse McConnell <[EMAIL PROTECTED]> a écrit :

> I use this setup successfully
> 
> ./src/main/webapp/WEB-INF
> ./src/main/webapp/WEB-INF/web.xml
> ./src/main/webapp/WEB-INF/client-config.wsdd
> ./src/main/webapp/WEB-INF/server-config.wsdd
> ./src/main/webapp/index.jsp
> ./src/main/webapp/fingerprint.jsp
> ./src/main/webapp/happyaxis.jsp
> ./src/main/webapp/i18nLib.jsp
> ./src/main/webapp/index.html
> 
> 
> On 9/20/05, Filip Polsakiewicz <[EMAIL PROTECTED]> wrote:
> > 
> > Hi all,
> > 
> > I am quite new to the maven war plugin. I have the following problem:
> > 
> > 
> > 
> > I set up the following directory strutcture:
> > 
> > 
> > 
> > Main / src / webapp
> > 
> > Main / src / webapp / WEB-INF
> > 
> > Main / src / java
> > 
> > Main / src / resources
> > 
> > 
> > 
> > I want to include some additional xml-files in my WEB-INF directory.
> > Unfortunately using the above structure and running maven war produces a

> > war
> > file where my WEB-INF directory is placed in the WEB-INF/classes 
> > directory.
> > How can I change this behaviour and where in the above structure do I
put 
> > my
> > jsp's?
> > 
> > 
> > 
> > Thanks Filip
> > 
> > 
> > 
> 
> 
> -- 
> jesse mcconnell
> 







___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

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


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

Re: additional xml-files in WEB-INF directory

[Yann Le Du]

Success here also with an XML file.

~   ./src/main/webapp/WEB-INF
~   +-- web.xml
~   +-- test.xml

results into :

~   ./target/artifactId-version/WEB-INF
~   +-- web.xml
~   +-- test.xml

Which version of Maven are you using ?

Also, you said you were using "Main / src / webapp", didn't you mean "src /
main / webapp" ?

Yann


--- Jesse McConnell <[EMAIL PROTECTED]> a écrit :

> I use this setup successfully
> 
> ./src/main/webapp/WEB-INF
> ./src/main/webapp/WEB-INF/web.xml
> ./src/main/webapp/WEB-INF/client-config.wsdd
> ./src/main/webapp/WEB-INF/server-config.wsdd
> ./src/main/webapp/index.jsp
> ./src/main/webapp/fingerprint.jsp
> ./src/main/webapp/happyaxis.jsp
> ./src/main/webapp/i18nLib.jsp
> ./src/main/webapp/index.html
> 
> 
> On 9/20/05, Filip Polsakiewicz <[EMAIL PROTECTED]> wrote:
> > 
> > Hi all,
> > 
> > I am quite new to the maven war plugin. I have the following problem:
> > 
> > 
> > 
> > I set up the following directory strutcture:
> > 
> > 
> > 
> > Main / src / webapp
> > 
> > Main / src / webapp / WEB-INF
> > 
> > Main / src / java
> > 
> > Main / src / resources
> > 
> > 
> > 
> > I want to include some additional xml-files in my WEB-INF directory.
> > Unfortunately using the above structure and running maven war produces a 
> > war
> > file where my WEB-INF directory is placed in the WEB-INF/classes 
> > directory.
> > How can I change this behaviour and where in the above structure do I put 
> > my
> > jsp's?
> > 
> > 
> > 
> > Thanks Filip
> > 
> > 
> > 
> 
> 
> -- 
> jesse mcconnell
> 







___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

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

Re: additional xml-files in WEB-INF directory

[Jesse McConnell]

I use this setup successfully

./src/main/webapp/WEB-INF
./src/main/webapp/WEB-INF/web.xml
./src/main/webapp/WEB-INF/client-config.wsdd
./src/main/webapp/WEB-INF/server-config.wsdd
./src/main/webapp/index.jsp
./src/main/webapp/fingerprint.jsp
./src/main/webapp/happyaxis.jsp
./src/main/webapp/i18nLib.jsp
./src/main/webapp/index.html


On 9/20/05, Filip Polsakiewicz <[EMAIL PROTECTED]> wrote:
> 
> Hi all,
> 
> I am quite new to the maven war plugin. I have the following problem:
> 
> 
> 
> I set up the following directory strutcture:
> 
> 
> 
> Main / src / webapp
> 
> Main / src / webapp / WEB-INF
> 
> Main / src / java
> 
> Main / src / resources
> 
> 
> 
> I want to include some additional xml-files in my WEB-INF directory.
> Unfortunately using the above structure and running maven war produces a 
> war
> file where my WEB-INF directory is placed in the WEB-INF/classes 
> directory.
> How can I change this behaviour and where in the above structure do I put 
> my
> jsp's?
> 
> 
> 
> Thanks Filip
> 
> 
> 


-- 
jesse mcconnell

Building eclipse plugins with maven, where can I find the eclipse jars?

[Lucas Persson]

Hi,

I want to build my eclipse plugins with maven (maven1)

Where can I find the eclipse jars to compile against?
Or has everybody put them in an internal repository?

I also got the maven-eclise-plugin-plugin but is it 
so that I have to maintain two lists of dependent jars;
one in project.xml and one in plugin.xml?
Or is that some trick which can generate one of these lists?

Many thanks!
/Lucas

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

Re: [m2] assembly plugin

[Daniel Schömer]

Hi.

Ashley Williams wrote:
> Does anyone know how to use assembly:assembly, in particular what the  
> descriptor is supposed to be? I did hardcode it as a path to my pom  
> from within my pom (that seems wrong) which made the plugin run  
> without errors, but I didn't see any output file.

As far as I could examine the source of the assembly plugin, the
descriptor is a xml file that contains a description of what to
asseble.  The "descriptor" property is a path to such a file and
descriptorId is the id of a descriptor that is known to the assembly
plugin.

Is seems the assembly descriptors currently provided by the assembly plugin
are there:

  
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-assembly-plugin/src/main/resources/assemblies/

I've successfully run assembly:assembly setting descriptorId to one of
the id in the provided assemblies ("bin", "src" or
"jar-with-dependencies").

  m2 assembly:assembly -Dmaven.assembly.descriptorId=bin

Regards,
Daniel Schömer


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

Sorry for the double posting (n.T.)

[Filip Polsakiewicz]

additional xml-files in WEB-INF directory

[Filip Polsakiewicz]

Hi all,

I am quite new to the maven war plugin. I have the following problem:

 

I set up the following directory strutcture:

 

Main / src / webapp

Main / src / webapp / WEB-INF

Main / src / java

Main / src / resources

 

I want to include some additional xml-files in my WEB-INF directory.
Unfortunately using the above structure and running maven war produces a war
file where my WEB-INF directory is placed in the WEB-INF/classes directory.
How can I change this behaviour and where in the above structure do I put my
jsp's?

 

Thanks Filip

additional xml-files in WEB-INF directory

[Filip Polsakiewicz]

Hi,

 I am quite new to the maven:war plugin. I set up the directories as
suggested (i.e. main/src/webapp) and added a WEB-INF Directory in the webapp
directory since I need to add some additional xml files (struts-config.xml).
Unfortunately when I run maven war the war file generated includes my
WEB-INF Directory under the WEB-INF/classes directory. How can I change this
behaviour?

 

Thanks, Filip

Re: [m2] Extending Eclipse plugin

[Kenney Westerhof]

On Tue, 20 Sep 2005, Rinku wrote:

> Hi,
>
> I have a use case where I need to reuse/extend the functionality
> provided by existing M2 Eclipse plugin. The use case involves creating
> "deployables" directory from defined project properties and some other
> updates to ".wtpmodules" contents.
>
> What I want to do is to create sort of a wrapper plugin that can
> delegate 'standard' goals to the Eclipse plugin and do some pre/post
> processing around these 'standard' goals. Could anyone please explain
> what would be a neat way to achieve this and keep the option of being
> able to reuse future Eclipse plugin releases but just updating the
> version numbers in pom.

I think it would be better if your changes are put in the eclipse plugin
(at least for the contents of the .wtpmodules). Creation of custom
directories on the other hand is not something the eclipse plugin should
do - the maven build should create those too as it needs it.. maybe just
use a target/... directory for that and let eclipse automatically create
it, like target/classes?

What are the exact changes? Do you think they are general enough
to be added to the eclipse plugin?

-- Kenney
>
> Thanks in advance for all the help.
>
> Cheers,
>
> Rahul
>
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

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

Re: ejb and war plugins (maven 1.1 beta2)

[jan_bar]

http://jira.codehaus.org/browse/MPWAR-50.

I am starting with maven and j2ee, so my opinion may be of small value. For
now I added:




Thanks, Jan

PS: Can I create dependency on plugin patch? Or at least check if the plugin
is of certain version and issue bug during build? The problem is that the
dependency is silently skipped.


"Arnaud HERITIER" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
I never used it but it seems to be a missing feature in the war plugin.
Can you open an issue. We'll fix it ASAP.
The behavior of the ejb plugin was certainly changed recently and the war
plugin wasn't updated.
We should add the support for types : ejb and ejb-client (generated if
maven.ejb.client.generate=true) in the war plugin.
WDYT ?

Arnaud

On 9/20/05, jan_bar <[EMAIL PROTECTED]> wrote:
>
> No answers so far, but this seems to be basic question for J2EE
> development
> with maven. Maybe I was not clear enough.
>
> The client code generated for EJB must be included in WAR file. I don't
> know
> how to do this with maven 1.1 beta 2 because war plugin copies only
> type=jar
> dependencies and EJB client code is type=ejb. Is this bug or I got
> something
> wrong?
>
> Jan
>
> "jan_bar" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi,
> >
> > ejb plugin places the EJB client code in repository in ejbs/ client>.jar.
> > However the war plugin uses only type=jar dependencies:
> >
> > (maven-war-plugin-1.6.1/plugin.jelly, line 149)
> >
> > 
> > 
> > 
> >
> > Seems like bug. How can I add my EJB client jar to WAR?
> >
> > Thanks, Jan
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>




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

Re: ejb and war plugins (maven 1.1 beta2)

[Arnaud HERITIER]

I never used it but it seems to be a missing feature in the war plugin.
Can you open an issue. We'll fix it ASAP.
The behavior of the ejb plugin was certainly changed recently and the war 
plugin wasn't updated.
We should add the support for types : ejb and ejb-client (generated if 
maven.ejb.client.generate=true) in the war plugin.
WDYT ?

Arnaud

On 9/20/05, jan_bar <[EMAIL PROTECTED]> wrote:
> 
> No answers so far, but this seems to be basic question for J2EE 
> development
> with maven. Maybe I was not clear enough.
> 
> The client code generated for EJB must be included in WAR file. I don't 
> know
> how to do this with maven 1.1 beta 2 because war plugin copies only 
> type=jar
> dependencies and EJB client code is type=ejb. Is this bug or I got 
> something
> wrong?
> 
> Jan
> 
> "jan_bar" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi,
> >
> > ejb plugin places the EJB client code in repository in ejbs/ client>.jar.
> > However the war plugin uses only type=jar dependencies:
> >
> > (maven-war-plugin-1.6.1/plugin.jelly, line 149)
> >
> > 
> > 
> > 
> >
> > Seems like bug. How can I add my EJB client jar to WAR?
> >
> > Thanks, Jan
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>