[m2] work with the mojo logger when implementing a configuration converter

[Olivier Lamy]

Hi,
I'm actually implementing a ConfigurationConverter. 
In order to made debugging, I need to get the mojo logger.
I include log4j (properties file in the resources) in the plugin and it
works.
But I don't like this way because it's not included with the maven
logger. 
Is there any way to configure the maven logger as a log4j appender ?
If not how can I do this ?
 
Thanks,
 
- Olivier
 


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 electronique et tous les fichiers joints ainsi que  les informations 
contenues dans ce message ( ci apres "le message" ), sont confidentiels et 
destines exclusivement a l'usage de la  personne a laquelle ils sont adresses. 
Si vous avez recu ce message par erreur, merci  de le renvoyer a son emetteur 
et de le detruire. Toutes diffusion, publication, totale ou partielle ou 
divulgation sous quelque forme que se soit non expressement autorisees de ce 
message, sont interdites.
** 

RE: Continuous Integration with Luntbuild

[Blaise Gosselin]

I managed doing it now, but setting the following property in Builders of type 
maven :
Directory to run Maven in : commons
 
It works, and my jar has been successfully constructed, but it has been failed 
for luntbuild.
I have the following output in my build_log.txt :
---
jar:jar:
[jar] Building jar: C:\Program 
Files\luntbuild\work\commons\commons\target\commons-1.0.jar
LA CONSTRUCTION A RÈUSSIE
Temps total: 28 secondes 
Fini le: lundi 28 novembre 2005 8:41:18 CET
 
Maven builder failed: build success condition not met!
---
 
How can I solve this ?
 
Thanks in advance...
 _ _ _
bgOnline

-Original Message-
From: Blaise Gosselin 
Sent: lundi 28 novembre 2005 8:37
To: Maven Users List
Cc: '[EMAIL PROTECTED]'
Subject: Continuous Integration with Luntbuild


Hello,
 
I'm currently trying the tool Luntbuild, which seems to be appropriate for my 
needs.
Nevertheless, I don't manage to make it work for one of my project.
I have a Subversion VCS repository, and one of my project is at the following 
url :
http://tomcat/svn/commons/trunk/commons
 
Thus, all the sources are under the directory commons/trunk/commons.
 
In luntbuild, I've defined a VCS adaptor, with the following repository url 
base: http://tomcat/svn/commons
Directory for trunk : trunk
...
modules : commons
 
==> when a checkout is done with luntbuild, I have the following structure:
luntbuild/work/commons/commons/...
 
But my maven project.xml file is under the last commons directory.
 
How can I solve this problem ?
 
Thanks in advance...
___ _ _ _
bgOnline

Re: [m2] dependency graph

[Wim Deblauwe]

Thanks for creating that page, we might be able to gather all the info
there.
I just wanted to say that I hope, you will not choose to use Graphviz, but
choose a full java solution. You don't want to bother users with special
installation things to have a dependency graph, especially since there are
other options.
AmbitiousGraph seems nice looking at the screenshot, but I think we need a
report that we can include in the site, not a stand-alon application. That
report should show an SVG or PNG (maybe that should then be configurable
depending on the browser they want to use)

regards,

Wim

2005/11/27, Brett Porter <[EMAIL PROTECTED]>:
>
> http://docs.codehaus.org/display/MAVEN/Dependency+Graphing
>
> On 11/25/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
> > Just for the record, here are 2 links that might ease the work:
> >
> > http://www.xml.com/pub/a/2004/09/08/tree.html
> > http://www.linguiste.org/syntax/tree/drawer/
> >
> > They show how to convert an xml tree structure to a SVG image.
> >
> > regards,
> >
> > Wim
> >
> >
> > 2005/11/25, Wim Deblauwe <[EMAIL PROTECTED]>:
> > >
> > > Well, maybe we need to bundle to effort to know where we are standing
> on
> > > some wiki page?
> > >
> > > regards,
> > >
> > > Wim
> > >
> > > 2005/11/25, Brett Porter <[EMAIL PROTECTED]>:
> > > >
> > > > Yes, its planned. We just have a very long todo list :)
> > > >
> > > > It is quite simple, as the artifact resolver has a listener with
> nodes
> > > > that can be used to get all the information, once a way is provided
> to
> > > > hook into the process.
> > > >
> > > > I think some others have worked on some related experiements
> (Joakim?)
> > > >
> > > > Cheers,
> > > > Brett
> > > >
> > > > On 11/25/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
> > > > > Hi,
> > > > >
> > > > > it would be really cool to have a plugin that shows all the
> > > > dependencies of
> > > > > your project in a graph. This graph could be in SVG or png or
> > > > whatever. Is
> > > > > there already such a plugin or plans for such a plugin? What
> graphing
> > > > > library do you think would be best to implement this kind of thing
> > > > (must be
> > > > > open source ofcourse)?
> > > > >
> > > > > With the maven 2 dependency mechanism, this can't be that hard.
> Get
> > > > your
> > > > > dependencies, then get the dependencies of your dependencies and
> so
> > > > on. Put
> > > > > all that in some kind of model that some library can turn into a
> nice
> > > > graph
> > > > > et voila! :)
> > > > >
> > > > > regards,
> > > > >
> > > > > Wim
> > > > >
> > > > >
> > > >
> > > >
> -
> > > > 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]
>
>

Continuous Integration with Luntbuild

[Blaise Gosselin]

Hello,
 
I'm currently trying the tool Luntbuild, which seems to be appropriate for my 
needs.
Nevertheless, I don't manage to make it work for one of my project.
I have a Subversion VCS repository, and one of my project is at the following 
url :
http://tomcat/svn/commons/trunk/commons
 
Thus, all the sources are under the directory commons/trunk/commons.
 
In luntbuild, I've defined a VCS adaptor, with the following repository url 
base: http://tomcat/svn/commons
Directory for trunk : trunk
...
modules : commons
 
==> when a checkout is done with luntbuild, I have the following structure:
luntbuild/work/commons/commons/...
 
But my maven project.xml file is under the last commons directory.
 
How can I solve this problem ?
 
Thanks in advance...
___ _ _ _
bgOnline

Re: [m2] Javadoc report with incorrect index.html page ?

[Christian Schulte]

Christian Schulte schrieb:


Brett Porter schrieb:


bug in the last release, fixed in SVN, release coming up soon. More
info in JIRA or the archives.



Is there some info on how to build a maven2 snapshot correctly ? I have 
build a snapshot by checking out trunk and doing a ./bootstrap.sh. So I 
have a maven-2.0.1-SNAPSHOT directory. When I now try to get the javadoc 
report by using that maven installation it still does not work and I am 
doing something wrong. So I removed my local repository and tried again 
but it still does not work. How do I build the javadoc-plugin myself then ?




I got it. Sorry for the inconvinience.

svn checkout 
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin 
maven-javadoc-plugin


cd maven-javadoc-plugin

mvn install

--
Christian


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

Re: [m2] Javadoc report with incorrect index.html page ?

[Christian Schulte]

Brett Porter schrieb:


bug in the last release, fixed in SVN, release coming up soon. More
info in JIRA or the archives.


Is there some info on how to build a maven2 snapshot correctly ? I have 
build a snapshot by checking out trunk and doing a ./bootstrap.sh. So I 
have a maven-2.0.1-SNAPSHOT directory. When I now try to get the javadoc 
report by using that maven installation it still does not work and I am 
doing something wrong. So I removed my local repository and tried again 
but it still does not work. How do I build the javadoc-plugin myself then ?


--
Christian


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

mevenide eclipse plugin and maven 2

[martin . kuhn]

Hi,

is there a possibility to work with the mevenide eclipse plugin and maven 
2 ?

TIA 

Martin




++
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] Repository

[Jason van Zyl]

Law Green-A20134 wrote:
> Jason,
> 
> Thank you so much for your patient reply! I have updated the diagram as 
> per your comments, please let me know if it need further update.

I might put the local repository box below the maven instance but I'm
not sure if you can control the layout. Otherwise it looks good!

>  
> And I guess it would be better to fake a sample suite to reflect the 
> topology, including settings.xml, pom.xml, maven-proxy.properties. I 
> would like to help with this task.  

We can definitely put together a guide for maven-proxy and the
associated setup. I'm sure users would find that helpful.

I'm about to head off to bed but if you want to try and start something
you're welcome to use the maven user wiki space:

http://docs.codehaus.org/display/MAVENUSER/Home

And I can work with you there if you like.

> BTW, I use UmlGraph (http://www.spinellis.gr/sw/umlgraph/) to generate 
> the diagram. The tool makes it an easy job drawing the diagram. To 
> generate the diagram shown above, all I have done is 17 lines of java 
> like code plus one command line. U can do it in one minute once u get 
> familiar with it.

Nice!

-- 

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] What happened to 'maven dist' ?

[Wendy Smoak]

On 11/27/05, Brett Porter <[EMAIL PROTECTED]> wrote:

> -DdescriptorId=src
>
> I'll republish the doc...

Note to self:  ignore documentation, _read_ error message.

Thanks. :)

--
Wendy

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

Re: [M2] Repository

[Wendy Smoak]

On 11/27/05, Law Green-A20134 <[EMAIL PROTECTED]> wrote:

> BTW, I use UmlGraph (http://www.spinellis.gr/sw/umlgraph/) to generate the
> diagram. The tool makes it an easy job drawing the diagram. To generate the
> diagram shown above, all I have done is 17 lines of java like code plus one
> command line. U can do it in one minute once u get familiar with it.
>


Neat. :)  Someone wrote a Maven 1 plugin for it, but I never could get it to
work...
http://maven-plugins.sourceforge.net/maven-dotuml-plugin/

Any chance of an m2 plugin ??

--
Wendy

Re: [m2] What happened to 'maven dist' ?

[Christian Schulte]

Wendy Smoak schrieb:

On 11/27/05, Brett Porter <[EMAIL PROTECTED]> wrote:


Yep!



http://maven.apache.org/plugins/maven-assembly-plugin/howto.html

$ mvn assembly:assembly -Dmaven.assembly.descriptorId=src

[ERROR] BUILD FAILURE
[INFO] ---
---
[INFO] You must specify descriptor or descriptorId
[INFO] ---

Any ideas?



mvn assembly:assembly -DdescriptorId=src ?

--
Christian

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

RE: [M2] Repository

[Law Green-A20134]

Jason,Thank you so much for your patient 
reply! I have updated the diagram as per your comments, please let me know if it 
need further update.

 
And I guess it would be better to fake a 
sample suite to reflect the topology, including settings.xml, pom.xml, 
maven-proxy.properties. I would like to help with this 
task.  
 
BTW, I use UmlGraph (http://www.spinellis.gr/sw/umlgraph/) 
to generate the diagram. The tool makes it an easy job drawing the diagram. To 
generate the diagram shown above, all I have done is 17 lines of java like code 
plus one command line. U can do it in one minute once u get familiar with 
it.Regards,Green-Original 
Message-From: Jason van Zyl [mailto:[EMAIL PROTECTED]]Sent: 
2005年11月28日 14:15To: Maven Users ListSubject: Re: [M2] 
RepositoryLaw Green-A20134 wrote:> Jason,>> It's 
almost done, really appreciate! The only thing I want to make> clear is 
the maven-proxy deployment,>> Do you suggest we deploy maven-proxy 
as follows:I think the picture from the maven-proxy box pointing to many 
repos is accurate but I think you might want to represent Maven as the active 
process that sits between maven-proxy and the local repository which is 
populated the active maven process i.e. the copy of maven run by each developer 
on their workstations. It is maven that is talking to your instance of 
maven-proxy, in essence the mediator between your local and remote repository. 
In this case maven-proxy is acting as the uber remote repository.Would 
be happy to try and integrate your diagram into this:http://maven.apache.org/guides/introduction/introduction-to-repositories.htmlWould certainly help people who are new to 
Maven.--jvz.Jason van Zyljason at 
maven.orghttp://maven.apache.orgbelieve 
nothing, no matter where you read it, or who has said it, not even if i have 
said it, unless it agrees with your own reason and your own common 
sense. -- 
Buddha-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] What happened to 'maven dist' ?

[Brett Porter]

-DdescriptorId=src

I'll republish the doc...

On 11/28/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> On 11/27/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> > Yep!
>
> http://maven.apache.org/plugins/maven-assembly-plugin/howto.html
>
> $ mvn assembly:assembly -Dmaven.assembly.descriptorId=src
>
> [ERROR] BUILD FAILURE
> [INFO] ---
> ---
> [INFO] You must specify descriptor or descriptorId
> [INFO] ---
>
> Any ideas?
>
> --
> Wendy
>
> -
> 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] What happened to 'maven dist' ?

[Wendy Smoak]

On 11/27/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> Yep!

http://maven.apache.org/plugins/maven-assembly-plugin/howto.html

$ mvn assembly:assembly -Dmaven.assembly.descriptorId=src

[ERROR] BUILD FAILURE
[INFO] ---
---
[INFO] You must specify descriptor or descriptorId
[INFO] ---

Any ideas?

--
Wendy

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

Re: [m2] Javadoc report with incorrect index.html page ?

[Christian Schulte]

Brett Porter schrieb:


bug in the last release, fixed in SVN, release coming up soon. More
info in JIRA or the archives.


Thanks for the info.

--
Christian


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

Re: [m2] Javadoc report with incorrect index.html page ?

[Brett Porter]

bug in the last release, fixed in SVN, release coming up soon. More
info in JIRA or the archives.

On 11/28/05, Christian Schulte <[EMAIL PROTECTED]> wrote:
> Hi,
>
> what may be the reason why the index.html at target/site/apidocs is the
> same as the index.html of the project/module. The javadoc is generated
> but the index.html inside target/site/apidocs is wrong. I know it worked
> a few days ago but now stopped working and I cannot find the mistake in
> my pom.
>
> --
> Christian
>
>
> -
> 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] Javadoc report with incorrect index.html page ?

[Christian Schulte]

Hi,

what may be the reason why the index.html at target/site/apidocs is the 
same as the index.html of the project/module. The javadoc is generated 
but the index.html inside target/site/apidocs is wrong. I know it worked 
a few days ago but now stopped working and I cannot find the mistake in 
my pom.


--
Christian


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

Re: [m2] What happened to 'maven dist' ?

[Brett Porter]

Yep!

On 11/28/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> What's the m2 equivalent of 'maven dist' ?  (It would build .tar.gz
> and .zip versions of both the binary and source distributions.)
>
> Is the 'assembly' plugin what I'm looking for?
>
> Thanks,
> Wendy
>
> -
> 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] What happened to 'maven dist' ?

[Wendy Smoak]

What's the m2 equivalent of 'maven dist' ?  (It would build .tar.gz
and .zip versions of both the binary and source distributions.)

Is the 'assembly' plugin what I'm looking for?

Thanks,
Wendy

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

Re: [M2] Repository

[Jason van Zyl]

Law Green-A20134 wrote:
> Jason,
> 
> It's almost done, really appreciate! The only thing I want to make clear 
> is the maven-proxy deployment,
> 
> Do you suggest we deploy maven-proxy as follows:

I think the picture from the maven-proxy box pointing to many repos is
accurate but I think you might want to represent Maven as the active
process that sits between maven-proxy and the local repository which is
populated the active maven process i.e. the copy of maven run by each
developer on their workstations. It is maven that is talking to your
instance of maven-proxy, in essence the mediator between your local and
remote repository. In this case maven-proxy is acting as the uber remote
repository.

Would be happy to try and integrate your diagram into this:

http://maven.apache.org/guides/introduction/introduction-to-repositories.html

Would certainly help people who are new to Maven.

-- 

jvz.

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

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

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

Re: [M2] Repository

[Jason van Zyl]

Jeff Jensen wrote:


I was wondering how to take your excellent email answers on this and put
them in the Maven doc somewhere...
A diagram is the icing... :-)


We are actually trying to encourage users to help in this respect by 
using the Confluence space that is accessible to anyone:


http://docs.codehaus.org/display/MAVENUSER/Home

If you can shape the response into a FAQ, mini guide, or introductory 
guide then they will be absorbed into the documentation. To this end I'm 
trying to create some tools to facilitiate this. For example the FAQ:


http://docs.codehaus.org/display/MAVENUSER/FAQs

I can now extract out of Confluence and turn into this:

http://maven.apache.org/auto-faq.html

Not perfect, but getting there.

So if users are willing to contribute documentation we will get it into 
the canonical documentation.





A strategy change for some questions with missing doc coverage could be to
create docs, publish, reply with URL, and ask if that answers the questions.


That's exactly what we're trying to do. We try to update the 
documentation so that we can point users at existing documentation but 
now anyone can do that. If you see a question that you can answer you 
can put it into the MavenUser space and point someone at it. 
Subsequently we will incorporate that into the canonical documentation.



Others can then more easily submit patches too.  Just a thought in case it
would work for you.


There are several JIRA components that correspond to documentation and 
we also have filters that try to pick off the issue with patches. So 
we're trying to absorb patches provided by users in the easiest way 
possible.


Also, in order to aid in the creation of patches I've got this in the works:

http://svn.apache.org/viewcvs.cgi/maven/sandbox/issue/maven-submit-plugin/

A plug-in that will allow you, as a user, to create a patch, create a 
JIRA issue, and attach a patch in one fell swoop with no annoying 
clicky-clicky in JIRA. Not that JIRA isn't good but creating a patch is 
tedious. The create patch plugin works I just need to get off my ass and 
deploy it for use. There's also a plugin for automatically submitting 
bundles for the repository. We are working to try and make this easier 
for users.




-
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 all have problems. How we deal with them is a measure of our worth.

 -- Unknown

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

RE: [M2] Repository

[Law Green-A20134]

Jason,It's almost done, really appreciate! The only 
thing I want to make clear is the maven-proxy deployment,Do you suggest 
we deploy maven-proxy as follows:Regards,Green-Original 
Message-From: Jason van Zyl [mailto:[EMAIL PROTECTED]]Sent: 2005年11月28日 
12:53To: Maven Users ListSubject: Re: [M2] RepositoryLaw 
Green-A20134 wrote:> Thanks Jason,>> They are clear. Here 
is my further questions:>> 1. local repository store artifacts 
from both central repository and snapshot repository, right?Your local 
repository will store all artifacts retrieved from remote respositories 
irrepsective of their location or what they store. As a user you only have one 
local repository. Developers of Maven take this as a given and is probably not 
well expressed in the documentation.> 2. dependency can be 
pre-released artifacts stored in snapshot repository?Short answer is 
yes.This is the practice we recommend: we have a release repository and 
a snapshot repository and so our snapshot dependencies typically come from a 
snapshot repository. But there is nothing stopping you from storing snapshots 
and release artifacts in one repository. You specify these policies in the 
repository definitions.> 3. distribution repository = internal 
repository?For an organization this will most likely be the case. Your 
internal repository may serve as the repository you deploy/distribute to, and 
may also serve as the primary remote repository for all users inside your 
organization. I should really whip up a diagram.> 4. If I want to 
setup my project with external repository and internal> repository and I 
want to have the looking up order to be> local->internal->external, 
what should I do?Looking up artifacts in your local repository happens 
automatically. If you have requested an artifact and it has been downloaded it 
will be used from your local repository. So really you want to control in which 
order your remote repositories are access be that inside or outside your 
firewall.> Further more, I hope all artifacts download from external 
repository> be stored in internal repository automatically. Does 
maven-proxy> designed for this?Yes, if you want to shield your 
inside-the-firewall users from any outside-the-firewall repositories then 
maven-proxy is what you want.It's generally good practice to use maven-proxy 
as it provides some indirection when referencing repositories in general whether 
they be internal or external to your organization.> But does that 
mean I have to distribute my released artifacts to a> proxy which seems 
weird to me?No, you would deploy to your designated internal repository 
and in turn your maven-proxy setup would refer to the internal repository 
location.There is currently no deployment that happens via 
maven-proxy.Maven-proxy is in essence a facade for a number of repositories 
and is strictly used for downloading not deployment.Hope that 
helps.--jvz.Jason van Zyljason at maven.orghttp://maven.apache.orgyou are never 
dedicated to something you have complete confidence in.No one is fanatically 
shouting that the sun is going to rise tomorrow.They know it is going to 
rise tomorrow. When people are fanatically dedicated to political or religious 
faiths or any other kind of dogmas or goals, it's always because these dogmas or 
goals are in doubt.  -- Robert Pirzig, Zen and the Art of 
Motorcycle 
Maintenance-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] Repository

[Jeff Jensen]

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, November 27, 2005 10:53 PM
> To: Maven Users List
> Subject: Re: [M2] Repository

> ... I should really whip up a diagram.

I was wondering how to take your excellent email answers on this and put
them in the Maven doc somewhere...
A diagram is the icing... :-)



A strategy change for some questions with missing doc coverage could be to
create docs, publish, reply with URL, and ask if that answers the questions.
Others can then more easily submit patches too.  Just a thought in case it
would work for you.


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

Re: Need assistance: Suppressing Version information during dependency resolution.

[Eric Redmond]

Yes, Maven has a definite opinion on this case, and that opinion is to
Maven-ize all projects. I won't argue either side here, but there is not a
way (nor does there appear to be in the near future) to grab just any random
file without a version number. So, here is my favorite method to deal with
handling versionless jars in projects that we do not control:

On your internal repository server, set your web server path to your project
repository (or, conversely, in your settings.xml file, point the server's
repository to your web-server's base path).

Run the install:install-file goal (
http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html)

This will generate a simple pom, as well as set your files in the correct
directory structure with groupId, artifactId and version information.

This may not be the "recommended method", however, it is very easy to
maintain.

Hope this helps!
Eric

On 11/27/05, Venkat Muthusamy <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> In Maven-2,
>
> The default dependency resolution
> /groupId/atifactId/$version/xyz-$version.jar
>
>
>
> The maven provides facility in pom to suppress groupId or artifactId, by
> using exclusions. But it does not allow suppressing version.
>
>
>
> I understand the version is important. We can control the version with our
> internal projects. But most of the external open source or vendor product
> jars do not always have version at the end.
>
>
>
> For example I am ok to store (in our internal repository) jars in version
> specific directory. But I do not like to rename the existing jar files
> with
> version information at the end of the jar.
>
> groupId/artifactId/1.3/j2ee.jar
>
> groupId/artifactId/1.3/j2ee-1.3.jar
>
>
>
> groupId/artifactId/1.3/graphics.jar
>
> groupId/artifactId/1.3/graphics-1.4.jar
>
>
>
> Thanks in advance,
>
>
>
> Venkat M
>
>

why .war cannot be a module of ear?

[jerry . tao]

Dear All:
  I create a EAR pom.xml file as follow:
 
   4.0.0
   ears
   ear
   jar
   1.0
   ear assembly

   
  
 pojos
 pojo
 1.0
  
 
   ejbs
   ejb
   1.0
 
  


   
  
 
   org.apache.maven.plugins
   maven-ear-plugin
   
  
  ear
  package
   
ear
  

   
   

 pojos
 pojo
 pojo-1.0.jar
   
   
 ejbs
 ejb
 ejb-1.0.jar
   
   
 wars
 war
 /custom-context-root
   
  
   
 
  
 


  
   


when compile, it run successfully, but when packaging, it report err as
following:\

 [INFO] Building jar: C:
\test\sample\ear\target\ear-1.0.jar
[INFO] [ear:ear {execution: ear}]
[INFO]
-
---
[ERROR] BUILD FAILURE
[INFO]
-
---
[INFO] Artifact[wars:war:war] is not a dependency of the project.
[INFO]
-
---
[INFO] For more information, run Maven with the -e switch
[INFO]
-
.


 the war project can compile, package and install successfully,  who can
tell me what 's the problem about the EAR project pom file?

thanks!

Regards
Jerry Tao

___
Hactl..Moving forward with you.

Best Air Cargo Terminal - Asia 2005
Air Cargo Terminal of the Year 2002, 2003 & 2004

Web: http://www.hactl.com

DISCLAIMER :-
The information contained in this message, including any attachment, is
confidential and may also be privileged. The information is intended only
for the person or entity to which it is addressed. Any review,
re-transmission, copying, storage, distribution or other use or disclosure
of this information by persons or entities other than the intended
recipient is prohibited. If you are not the intended recipient, please
contact the sender immediately by return email and delete this message from
your system. Thank you.



__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

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

Re: [M2] Repository

[Jason van Zyl]

Law Green-A20134 wrote:
> Thanks Jason,
> 
> They are clear. Here is my further questions:
> 
> 1. local repository store artifacts from both central repository and snapshot 
> repository, right? 

Your local repository will store all artifacts retrieved from remote
respositories irrepsective of their location or what they store. As a
user you only have one local repository. Developers of Maven take this
as a given and is probably not well expressed in the documentation.

> 2. dependency can be pre-released artifacts stored in snapshot repository?

Short answer is yes.

This is the practice we recommend: we have a release repository and a
snapshot repository and so our snapshot dependencies typically come from
a snapshot repository. But there is nothing stopping you from storing
snapshots and release artifacts in one repository. You specify these
policies in the repository definitions.

> 3. distribution repository = internal repository?

For an organization this will most likely be the case. Your internal
repository may serve as the repository you deploy/distribute to, and may
also serve as the primary remote repository for all users inside your
organization. I should really whip up a diagram.

> 4. If I want to setup my project with external repository and internal 
> repository and I 
> want to have the looking up order to be local->internal->external, what 
> should I do? 

Looking up artifacts in your local repository happens automatically. If
you have requested an artifact and it has been downloaded it will be
used from your local repository. So really you want to control in which
order your remote repositories are access be that inside or outside your
firewall.

> Further more, I hope all artifacts download from external 
> repository be stored in internal repository automatically. Does maven-proxy
> designed for this? 

Yes, if you want to shield your inside-the-firewall users from any
outside-the-firewall repositories then maven-proxy is what you want.
It's generally good practice to use maven-proxy as it provides some
indirection when referencing repositories in general whether they be
internal or external to your organization.

> But does that mean I have to distribute my released 
> artifacts to a proxy which seems weird to me?

No, you would deploy to your designated internal repository and in turn
your maven-proxy setup would refer to the internal repository location.
There is currently no deployment that happens via maven-proxy.
Maven-proxy is in essence a facade for a number of repositories and is
strictly used for downloading not deployment.

Hope that helps.

-- 

jvz.

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

you are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

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

Need assistance: Suppressing Version information during dependency resolution.

[Venkat Muthusamy]

Hi,

In Maven-2,

The default dependency resolution
/groupId/atifactId/$version/xyz-$version.jar



The maven provides facility in pom to suppress groupId or artifactId, by
using exclusions. But it does not allow suppressing version.



I understand the version is important. We can control the version with our
internal projects. But most of the external open source or vendor product
jars do not always have version at the end.



For example I am ok to store (in our internal repository) jars in version
specific directory. But I do not like to rename the existing jar files with
version information at the end of the jar.

groupId/artifactId/1.3/j2ee.jar

groupId/artifactId/1.3/j2ee-1.3.jar



groupId/artifactId/1.3/graphics.jar

groupId/artifactId/1.3/graphics-1.4.jar



Thanks in advance,



Venkat M

RE: [M2] Repository

[Law Green-A20134]

Thanks Jason,

They are clear. Here is my further questions:

1. local repository store artifacts from both central repository and snapshot 
repository, right? 
2. dependency can be pre-released artifacts stored in snapshot repository?
3. distribution repository = internal repository?
4. If I want to setup my project with external repository and internal 
repository and I want to have the looking up order to be 
local->internal->external, what should I do? Further more, I hope all artifacts 
download from external repository be stored in internal repository 
automatically. Does maven-proxy designed for this? But does that mean I have to 
distribute my released artifacts to a proxy which seems weird to me?

Regards,
Green

-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
Sent: 2005年11月28日 11:59
To: Maven Users List
Subject: Re: [M2] Repository

Law Green-A20134 wrote:
> Hi,
>  
> Can anyone give me a clear description of the following concepts and 
> their role in M2 build system:

They all share the same directory structure (as a file system is the most 
common way -- really the only way right now --  to house a repository).

> 1. remote repository

Where you the user may get artifacts from. Can be located anywhere and accessed 
by any protocol supported by Wagon (ftp/scp/http/file/...)

> 2. central repository

A special remote repository which is situated at www.ibiblio.org/maven2/, this 
is the remote repository where you would find most OSS artifacts.

> 3. snapshot repository

We do not store snapshots with released artifacts anymore. A snapshot 
repository is a remote repository specifically for housing non-release code.

> 4. local repository

The directory structure on your local machine which stores all the artifacts 
required by all the projects on your system.

> 5. private repository
> 6. intranet repository

Same thing and these are internal repositories. A remote repository inside your 
firewall i.e a repostory not on your machine but in the confines of your 
organization. You might have internal release/snapshot repos as well.

> 7. distribution repository

Usually an internal repository where you deploy your artifacts. Here again you 
may have release/snapshot repositories.

This might help as well:

http://maven.apache.org/guides/introduction/introduction-to-repositories.html

> Regards,
> Green
> 


-- 

jvz.

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

Three people can keep a secret provided two of them are dead.

  -- Unknown

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

[Jason van Zyl]

Law Green-A20134 wrote:

Hi,
 
Can anyone give me a clear description of the following concepts and

their role in M2 build system:


They all share the same directory structure (as a file system is the 
most common way -- really the only way right now --  to house a repository).



1. remote repository


Where you the user may get artifacts from. Can be located anywhere and 
accessed by any protocol supported by Wagon (ftp/scp/http/file/...)



2. central repository


A special remote repository which is situated at 
www.ibiblio.org/maven2/, this is the remote repository where you would 
find most OSS artifacts.



3. snapshot repository


We do not store snapshots with released artifacts anymore. A snapshot 
repository is a remote repository specifically for housing non-release code.



4. local repository


The directory structure on your local machine which stores all the 
artifacts required by all the projects on your system.



5. private repository
6. intranet repository


Same thing and these are internal repositories. A remote repository 
inside your firewall i.e a repostory not on your machine but in the 
confines of your organization. You might have internal release/snapshot 
repos as well.



7. distribution repository


Usually an internal repository where you deploy your artifacts. Here 
again you may have release/snapshot repositories.


This might help as well:

http://maven.apache.org/guides/introduction/introduction-to-repositories.html


Regards,
Green




--

jvz.

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

Three people can keep a secret provided two of them are dead.

 -- Unknown

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

[M2] Repository

[Law Green-A20134]

Hi,
 
Can anyone give me a clear description of the following concepts and
their role in M2 build system:
 
1. remote repository
2. central repository
3. snapshot repository
4. local repository
5. private repository
6. intranet repository
7. distribution repository
 
Regards,
Green

Re: [m2] Configure output folder in eclipse plugin

[Barry Kaplan]

Kees de Kooter wrote:

Is it possible to control which output folders the eclipse plugin puts
into the .classpath file? I tried setting the outputDirectory property
in the plugin configuration but that did not have any effect.


I use this and it works:

   
   
   
   
   org.apache.maven.plugins
   maven-eclipse-plugin
   
   target-eclipse
   
   
   
   ...


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

Re: Seperate local repository for plugins?

[Brett Porter]

The other issue should cover it as you'd just delete your local
project repository - feel free to vote and comment on your case.

- Brett

On 11/28/05, Barry Kaplan <[EMAIL PROTECTED]> wrote:
> Brett Porter wrote:
> > Not yet, but a bug was filed yesterday for a similar issue (per
> > project local repository, not a separate one for plugins as such).
> >
> > What is your use case?
>
> When trying to get a rather large set of project dependencies sorted
> out, I frequently delete my local repository to ensure that the build
> will work on a clean checkout. But I don't really want to delete the
> plugins, only the projects associated with the project I'm working with.
>
> Really, this request is nothing more than a time-saver to save having to
> download the plugins.
>
> -barry
>
> -
> 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: Seperate local repository for plugins?

[Barry Kaplan]

Brett Porter wrote:

Not yet, but a bug was filed yesterday for a similar issue (per
project local repository, not a separate one for plugins as such).

What is your use case?


When trying to get a rather large set of project dependencies sorted 
out, I frequently delete my local repository to ensure that the build 
will work on a clean checkout. But I don't really want to delete the 
plugins, only the projects associated with the project I'm working with.


Really, this request is nothing more than a time-saver to save having to 
download the plugins.


-barry

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

Re: inheriting from plugins

[Anuerin Diaz]

On 11/28/05, Srepfler Srgjan <[EMAIL PROTECTED]> wrote:
> Anuerin Diaz wrote:
>
> >On 11/27/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> >
> >
> >>No, I mean using libraries in a dependency fashion, rather than inheritance.
> >>
> >>
> >>
> >
> >sorry but im lost on how to implement this 'dependency fashion'. it
> >might have just been terminologies or it can be a whole ballpark. :)
> >basically my understanding of that is if i want to depend on a library
> >then i should have a list of the API that i could use which is
> >perfectly alright if i have those API handy. i am opting for
> >inheritance since most of the code in the assembly plugin is reusable
> >and i dont want to code them again in our plugin. thinking back this
> >also might not be prudent since i am not sure how parent methods will
> >perform with child variables. i guess i have to take a quick crash
> >review on oop.
> >
> >
> Perhaps they mean you can wrap the base class in your class and build on
> top of it? (I'm just guessing)
>

wrapping by inheritance was my initial goal, so i can only override
the methods that we need to. dependency building might be something
like instantiating an object and using it but i am not sure if
instantiating plugins will have them configured as described in the
pom.

ciao!


--

"Programming, an artform that fights back"

Anuerin G. Diaz
Registered Linux User #246176
Friendly Linux Board @ http://mandrivausers.org/index.php
http://capsule.ramfree17.org , when you absolutely have nothing else
better to do

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

Re: inheriting from plugins

[Srepfler Srgjan]

Anuerin Diaz wrote:


On 11/27/05, Brett Porter <[EMAIL PROTECTED]> wrote:
 


No, I mean using libraries in a dependency fashion, rather than inheritance.

   



sorry but im lost on how to implement this 'dependency fashion'. it
might have just been terminologies or it can be a whole ballpark. :)  
basically my understanding of that is if i want to depend on a library

then i should have a list of the API that i could use which is
perfectly alright if i have those API handy. i am opting for
inheritance since most of the code in the assembly plugin is reusable
and i dont want to code them again in our plugin. thinking back this
also might not be prudent since i am not sure how parent methods will
perform with child variables. i guess i have to take a quick crash
review on oop.
 

Perhaps they mean you can wrap the base class in your class and build on 
top of it? (I'm just guessing)


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

Re: inheriting from plugins

[Anuerin Diaz]

On 11/27/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> No, I mean using libraries in a dependency fashion, rather than inheritance.
>

sorry but im lost on how to implement this 'dependency fashion'. it
might have just been terminologies or it can be a whole ballpark. :)  
basically my understanding of that is if i want to depend on a library
then i should have a list of the API that i could use which is
perfectly alright if i have those API handy. i am opting for
inheritance since most of the code in the assembly plugin is reusable
and i dont want to code them again in our plugin. thinking back this
also might not be prudent since i am not sure how parent methods will
perform with child variables. i guess i have to take a quick crash
review on oop.

> plexus-utils contains the DirectoryScanner class from Ant if you'd
> like a lighter dependency for that.
>

great. my beef is looking at the code of maven plugins (via the web
frontend since i cant use svn at the office), most use classes from
plexus utils. as a normal user, i would say that i can find more
information on the plexus website at codehaus but then again i am
facing the same blank wall when it comes to documentation
availability. i can even find the correct site for plexus utils. i
admit this is no longer a maven problem but since maven uses plexus
intensively then logic dictates that some form of documentation is
available to guide users in understanding how things work and what can
be done to extend and add to the existing functionalities-

> Our priorities for documentation are:
> 1) pure user documentation on Maven feature usage
> 2) plugin developer documentation and related javadoc
> 3) maven developer internals documentation and related javadoc
>

which is well and good. most of the javadoc problem is not even
directly maven-related. one thing that i find interesting is that i am
seeing a lot of maven-built maven-used utilities and the projects that
publish javadocs are rare even if there is a maven plugin for it. i am
amazed at the work being accomplished by the maven team (and other
people using these libraries) because they either have the means to
get all the source codes and generate the javadocs themselves, or else
they are really gifted coders. the rest of us who do not fit in those
categories are left twiddling our thumbs and scratcing our heads.

sorry if my mail is sounding like a rant. i am a convert, but it gets
pretty frustrating telling my superiors that most projects built by
maven do not even publish maven-generated reports. my coding skills
are only average but it does not inspire confidence when they see me
scrambling to get documentation so i can finish my takss and all the
while i am telling them that their migration to maven is a sound move.

ciao!

> On 11/27/05, Anuerin Diaz <[EMAIL PROTECTED]> wrote:
> > thanks brett. by composition you mean coding from scratch? currently i
> > am doing that but i was hoping to re-use some of the code in the
> > plugins. as it is i am going to use ant classes for directory scanning
> > and processing because most of the classes used in the code do not
> > have javadocs (and they seem to have low priority) to guide new users.
> > that is one issue that i have beef with but we have other alternatives
> > so we might as well leverage on that.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--

"Programming, an artform that fights back"

Anuerin G. Diaz
Registered Linux User #246176
Friendly Linux Board @ http://mandrivausers.org/index.php
http://capsule.ramfree17.org , when you absolutely have nothing else
better to do

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

Repackaging dependent project artifacts

[Ryan Smith]

I'm investigating switching our build process from Ant to Maven.

 

I've run through the multi-project example, but I'm unclear as to how I
would embed one project's jar artifact within another.  I kind of expected
to be able to specify a package type of "jarjar" to ensure that the
artifacts (simple jars) of any dependent projects are included, but that the
default packaging types appear to be limited to jar/ejb/war.  I'm assuming
the package types are extensible and I'm guessing that someone has already
had the same need.  Can someone point me in the right direction?

 

Thanks,

Ryan

Current date in filter resource files

[Kevin Galligan]

During out current ant build process, we do a property filter replace 
setting a version string.  During development and testing, we set the 
value with a string with the current date and time.  When doing a 
release build we manually supply that value.


Is there a way to get the current time or timestamp reference?

I've seen 'SNAPSHOT' replaced with some time of timestamp.  I don't  
remember where (might have been m1).  If there was a way to get that, it 
would be about perfect.  Otherwise, just a way to get the current time 
or date as a string.  For a release build we could provide a value manually.


Thanks in advance,
-Kevin

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

Re: Seperate local repository for plugins?

[Brett Porter]

Not yet, but a bug was filed yesterday for a similar issue (per
project local repository, not a separate one for plugins as such).

What is your use case?

- Brett

On 11/28/05, Barry Kaplan <[EMAIL PROTECTED]> wrote:
> I would like to use a separate local repository for maven plugins and
> application projects. Is this possible?
>
> --
> barry kaplan
> [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]

[m2] repository link

[Adam Hardy]

I always have to look really hard to find the link to ibiblio for the 
repository. Is it possible that someone could put it in a more prominent 
place on the maven website? e.g. the 'where is it' page?


BTW, http://maven.apache.org/configuration.html is giving me a 
page-not-found error.



Thanks
Adam

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

Seperate local repository for plugins?

[Barry Kaplan]

I would like to use a separate local repository for maven plugins and 
application projects. Is this possible?


--
barry kaplan
[EMAIL PROTECTED]

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

Re: Maven proxy

[Nick Sieger]

>
>
> Id' like to announce an ongoing effort to make a usable caching-proxy
> engine useful for corporate (or group) proxying of Maven repositories
> (Yes, i'm aware of maven-proxy on Codehaus, but alternatives makes world
> beautiful).
>
> I would like to hear comments, ideas. Anybody interested? Anybody to
> jump in?



Somewhat related, I just released maven-proxy.rb (
http://radio.weblogs.com/0141460/2005/11/26.html#a91) which is a maven-proxy
substitute written as a Ruby CGI script.  I haven't used it heavily enough
yet to know how it will scale, but thought I'd mention it and if anyone
finds it useful please give me a shout!

Cheers,
/Nick

Re: inheriting from plugins

[Brett Porter]

No, I mean using libraries in a dependency fashion, rather than inheritance.

plexus-utils contains the DirectoryScanner class from Ant if you'd
like a lighter dependency for that.

Our priorities for documentation are:
1) pure user documentation on Maven feature usage
2) plugin developer documentation and related javadoc
3) maven developer internals documentation and related javadoc

On 11/27/05, Anuerin Diaz <[EMAIL PROTECTED]> wrote:
> thanks brett. by composition you mean coding from scratch? currently i
> am doing that but i was hoping to re-use some of the code in the
> plugins. as it is i am going to use ant classes for directory scanning
> and processing because most of the classes used in the code do not
> have javadocs (and they seem to have low priority) to guide new users.
> that is one issue that i have beef with but we have other alternatives
> so we might as well leverage on that.

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

Re: writing a new plugin

[Ashley Williams]

Hi Brill,

You could try the mant (maven-ant) plugin library I'm working on.  
Essentially it handles all the ant stuff so that you just need to  
write a single class like the one below that wraps ant
webdoclet - add required dependencies to your pom.xml as per usual.  
Just copy an existing project eg https://svn.codehaus.org/mojo/trunk/ 
mojo/mojo-sandbox/webdoclet-maven-plugin/ and you could have all of  
your ant tasks done in an hour, one mojo per task.


---
(sample-ear-proj in webdoclet-maven-plugin subdirectory has example  
usage)


package org.codehaus.mojo.webdoclet;

/**
* @goal webdoclet
* @phase generate-sources
* @requiresDependencyResolution test
*/
public class WebDocletMojo extends AbstractMojo
{
/**
 * @parameter expression="${project}"
 * @required
 * @readonly
 */
private MavenProject project;

/**
 * @parameter
 * @required
 */
private String task;

public void execute()
throws MojoExecutionException, MojoFailureException
{
// mappings: mant autofills in the ant task parameters on  
the LHS with
// the maven properties on the RHS so users don't need to  
supply them


String[] mappings = new String[] {
"@destDir",  
MantGoal.JAVA_GEN,

"deploymentdescriptor/@destDir", MantGoal.WEB_INF_GEN,
"fileset/@dir",   
MantGoal.JAVA,
"jbosswebxml/@destDir",  
MantGoal.WEB_INF_GEN

};
String taskdefClass = "xdoclet.modules.web.WebDocletTask";

new MantGoal(this, project, taskdefClass, task,  
mappings).execute();

}
}

Just check out codehaus mojo project and build mant first - directly  
under the mojo-sandbox directory.


- Ashley


On 27 Nov 2005, at 11:13, puschteblume wrote:

You are right. There isn't a migration strategy from maven1 to  
maven2 as I know, or can see. I have read that there will be groovy  
supported if it reaches the final version state. Within groovy ant  
is supported. Currently it helps you to start here:


http://ant.apache.org/manual/antexternal.html

You should also check in advance the groovy site to check if your  
requirements can match the groovy functions for ant integration.


http://groovy.codehaus.org/Ant+Scripting

As the plugins are distributed in jar file format it isn't easy to  
share your current ant scripts. Maybe you can think about to  
package your ant scripts in the jar file, extract and use it. I  
know, it isn't a nice way but maybe other people here have good  
ideas how to do that or can provide a better way.


Good luck
Heiko

Brill Pappin wrote:


I'm about to embark on writing a maven 2 plugin for Antenna.

Antenna has existing Ant tasks defined (in fact its an Ant task lib).

In Maven 1 it was fairly easy to implement a Maven plugin using  
ant tasks
because you could simple call them int he plugin... how would that  
type of

conversion be done for Maven 2?

So far the best I can see is to create a new Mojo that mirrors the  
Ant

task(s).

Is there documentation some place on converting an Ant task to a  
maven goal?





-
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: writing a new plugin

[puschteblume]

You are right. There isn't a migration strategy from maven1 to maven2 as 
I know, or can see. I have read that there will be groovy supported if 
it reaches the final version state. Within groovy ant is supported. 
Currently it helps you to start here:


http://ant.apache.org/manual/antexternal.html

You should also check in advance the groovy site to check if your 
requirements can match the groovy functions for ant integration.


http://groovy.codehaus.org/Ant+Scripting

As the plugins are distributed in jar file format it isn't easy to share 
your current ant scripts. Maybe you can think about to package your ant 
scripts in the jar file, extract and use it. I know, it isn't a nice way 
but maybe other people here have good ideas how to do that or can 
provide a better way.


Good luck
Heiko

Brill Pappin wrote:


I'm about to embark on writing a maven 2 plugin for Antenna.

Antenna has existing Ant tasks defined (in fact its an Ant task lib).

In Maven 1 it was fairly easy to implement a Maven plugin using ant tasks
because you could simple call them int he plugin... how would that type of
conversion be done for Maven 2?

So far the best I can see is to create a new Mojo that mirrors the Ant
task(s).

Is there documentation some place on converting an Ant task to a maven goal?
 




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

Re: [M1] Maven with Websphere Application Developer anyone?

[Dion Gillard]

Are you using


  true


on the dependency?

On 11/25/05, Weston, Toby <[EMAIL PROTECTED]> wrote:
> Hi Lee,
>
> Thanks for the info, could you outline how you got Websphere to handle the
> JAR's correctly? If I set the classpath of a webapp in the Maven way (ie,
> extend a variable MAVEN_REPO\foo.jar) if doesn't export / deploy this under
> the WEB-INF\lib folder. Does that make sense?
>
> Thanks,
> Toby
>
>   _
>
> From: Lee Meador [mailto:[EMAIL PROTECTED]
> Sent: 22 November 2005 21:07
> To: Maven Users List
> Cc: Weston, Toby
> Subject: Re: [M1] Maven with Websphere Application Developer anyone?
>
>
> I worked on a project last year that was using WSAD 5.1.2 with version 1 of
> Maven. It worked ok but we didn't get everything we wanted. My memory is
> fuzzy and I don't have access to the project files any more.
>
> 1) We could use WSAD with the folder structure Maven wants just fine.
>
> 2) We had a sort-of-base-project with things set up to build all the other
> projects as subprojects.
>
> 3) We would run Maven from the command line. Some developers set it up as an
> external tool to just run.
>
> 4) The projects would build inside WSAD (too) and we could deploy that way
> to the built in Websphere to test things.
>
> 5) That project had a Swing front end that talked directly to EJBs with
> Hibernate in the back. There was also a tiny little web app that did little
> more than show you the version number of the back end. Every "layer" was in
> a seperate WSAD project. That implies there were ejb projects, web projects
> and java projects.
>
> Hope this helps.
>
> -- Lee Meador
>
>
> On 11/22/05, Weston, Toby <[EMAIL PROTECTED]
>  > wrote:
>
> Hi Folks,
>
> Is anyone using Maven based structures (in particular J2EE ones like
> webapps) with Websphere Application Developer (WSAD) or Rational Application
> Developer?
>
> I was just after any horror/success stories and if you can make the project
> structure co-exist in harmony.
>
> Thanks in advance,
> Toby
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> 
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>
>
>
>
>
>
> --
> -- Lee Meador
> Sent from gmail. My real email address is [EMAIL PROTECTED]
> 
>
>


--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw

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