Ok cool... pfeww... I'm lucky as I've implemented 2/ yesterday night
(now in CVS) :-)
Thanks
-Vincent
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 19 June 2003 08:03
> To: Maven Developers List
> Subject: Re: Problems of EJB plugin and Dependencies down
I'm +0 on 2/ and -1 on 1/
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
"Vincent Massol" <[EMAIL PROTECTED]> wrote on 19/06/2003 02:01:04 AM:
> Hi,
>
> The EJB plugin ejb:install goal installs its artifacts in
> /e
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-505
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-504
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-503
Here is an overview of the issue:
--
bwalding2003/06/18 15:35:13
Modified:src/java/org/apache/maven/cli CLIManager.java
Log:
Clarifying comments
Revision ChangesPath
1.9 +5 -3 maven/src/java/org/apache/maven/cli/CLIManager.java
Index: CLIManager.java
The following issue has been updated:
Updater: Steve Ovens (mailto:[EMAIL PROTECTED])
Date: Wed, 18 Jun 2003 5:40 PM
Comment:
Here is my log from doing a "maven clean".
Changes:
Attachment changed from to maven.log
-
Michal,
I have committed a quick patch for EJB dependency handling so that
extensions for the EJB type artifacts is ".jar" and not ".ejb".
I hope I haven't broken anything. I have tested it successfully on my
current project.
Thanks
-Vincent
> -Original Message-
> From: Michal Maczka [m
vmassol 2003/06/18 14:50:14
Modified:src/java/org/apache/maven/project Dependency.java
xdocschanges.xml
Added: src/java/org/apache/maven/project ArtifactType.java
Log:
Added dependency type mapping to support extensions different than the artifact
type. Th
Message:
The following issue has been closed.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-196
Here is an overview of the issue:
--
Message:
The following issue has been closed.
Resolver: Vincent Massol
Date: Wed, 18 Jun 2003 5:04 PM
Duplicate for 496
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-497
Here is an
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-502
Here is an overview of the issue:
--
The following comment has been added to this issue:
Author: Aslak Hellesøy
Created: Wed, 18 Jun 2003 5:00 PM
Body:
NO!!
The current XDoclet 1.2b3 release is broken, so don't upload the jars before it's been
fixed. Someone from the XDoclet team will upload the jars.
Actually,
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-501
Here is an overview of the issue:
--
The following comment has been added to this issue:
Author: Warner Onstine
Created: Wed, 18 Jun 2003 5:01 PM
Body:
Forgot to mention it's the 1.0-dev (or alpha) version)
-
View the issue:
http://jira.codehaus.or
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-500
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-499
Here is an overview of the issue:
--
> I see 2 solutions:
>
> 1/ Add a property called false and if found the
> said dependency is not added to the Classpath?
>
> or
>
> 2/ Define a list of well known artifact types. That would server 2
> purposes:
> a- to know if the said dependency type should be added to the classpath
> b- to know
> > -Original Message-
> > From: Michal Maczka [mailto:[EMAIL PROTECTED]
> > Sent: 18 June 2003 21:13
> > To: Maven Developers List
> > Subject: RE: Recent changes in war plugin
> >
> >
> > > This already exists in Ant: it's called
> > > (http://ant.apache.org/manual/CoreTasks/manifest.h
Michal,
It seems we are in agreement in the end :-) I'm all for using Java as I
mentioned in my first email on this subject (and I do agree with all
your points below except point f)). My only comment was about
re-implementing the Zip/Jar/War tasks (and possibly the Manifest one
too).
Thanks
-Vin
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2003 8:46 PM
> To: 'Maven Developers List'
> Subject: RE: Recent changes in war plugin
>
>
>
>
> > -Original Message-
> > From: Michal Maczka [mailto:[EMAIL PROTECTED]
> > Sent: 18 Ju
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 21:09
> To: Maven Developers List
> Subject: RE: New WAR changes problems
[snip]
> > >
> > > > > artifact="foo"
> > > type="war"
> > > project="${pom}"
> > >
> > > >
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 21:13
> To: Maven Developers List
> Subject: RE: Recent changes in war plugin
>
>
> > This already exists in Ant: it's called
> > (http://ant.apache.org/manual/CoreTasks/manifest.html). And you ca
> This already exists in Ant: it's called
> (http://ant.apache.org/manual/CoreTasks/manifest.html). And you can use
> it from java too... :-) It weights 37K and contains lots of useful code.
> Why start reimplementing it again?
>
It's about different thing. There is no central place in maven whi
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2003 8:23 PM
> To: 'Maven Developers List'
> Subject: RE: New WAR changes problems
>
>
>
>
> > -Original Message-
> > From: Michal Maczka [mailto:[EMAIL PROTECTED]
> > Sent: 18 June 2
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 12:44
> To: 'Maven Developers List'
> Subject: RE: Recent changes in war plugin
>
>
> > > >
> > >
> > > What's so magical in ant war task?
> >
> > It's written, fully supports the war model and has
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 19:44
> To: Maven Developers List
> Subject: RE: New WAR changes problems
>
[snip]
> > there is no way to rename the war... One solution (not nice) would
to
> > perform a copy prior to calling .
>
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 19:53
> To: Maven Developers List
> Subject: RE: Problems of EJB plugin and Dependencies download
>
> This is partially fixed in maven-new (Repository Layout Service)
> So you can assign different l
The following issue has been updated:
Updater: Howard M. Lewis Ship (mailto:[EMAIL PROTECTED])
Date: Wed, 18 Jun 2003 1:32 PM
Comment:
This is from the 2.5.1 release.
The complete distro is at:
http://prdownloads.sourceforge.net/jboss/javassist-2.5.1.zip?use_mirror=aleron
Chan
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-498
Here is an overview of the issue:
--
The following issue has been updated:
Updater: Howard M. Lewis Ship (mailto:[EMAIL PROTECTED])
Date: Wed, 18 Jun 2003 1:31 PM
Changes:
Attachment changed from to javassist.txt
-
For a full history of
This is partially fixed in maven-new (Repository Layout Service)
So you can assign different layouts for different types.
E.g. for ejb it is (see layout-properties in maven-new/core/src/conf)
# EJB
ejb=${groupId}/ejbs/${artifactId}-${version}.jar
There is one more problem with ejbs.
There are no
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2003 5:45 PM
> To: 'Maven Developers List'
> Subject: New WAR changes problems
>
>
> Hi,
>
> I have 2 problems with the new changes brought to the war plugin WRT
> artifact deployment:
>
> 1/
Hi,
The EJB plugin ejb:install goal installs its artifacts in
/ejbs/-.jar (note the "jar" extension").
However, the maven dependency resolver looks for a file named:
/ejbs/-.ejb (not the "ejb" extension)
Thus it fails to find the artifact...
Several solutions:
1/ All jar files (.ear, .jar, .wa
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 17:45
> To: 'Maven Developers List'
> Subject: New WAR changes problems
>
> Hi,
>
> I have 2 problems with the new changes brought to the war plugin WRT
> artifact deployment:
>
> 1/ When I run m
Hi,
I have 2 problems with the new changes brought to the war plugin WRT
artifact deployment:
1/ When I run maven, I get:
war:war:
[echo] Building WAR everest-csrweb
[war] Updating war:
E:\Vma\Projets\Encours\tsss\everest\dev\modules\csrweb\target\everest-cs
rweb
.war
Copying: from
'E:\V
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-497
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-496
Here is an overview of the issue:
--
Michal Maczka wrote:
...
Last time I am asking:
Does anybody has something against building war ___always__ in two distinct
steps?
a) copying to build area (somewhere in target/ )
b) making a jar archive
Yes, this is the best way to do it. If your servlet engine can use
exploded webapps it
> > >
> >
> > What's so magical in ant war task?
>
> It's written, fully supports the war model and has gone through lots of
> testing.
>
OK I agree. But if we all have all files in given folder and we just want
to archive it why we should care? It's just fairly simple thing.
Do we need realy w
--- Michal Maczka <[EMAIL PROTECTED]> wrote:
> What's so magical in ant war task?
Nothing. I would say, that I never used it before
maven - jar was just fine for me.
> And personally I think that as much as possible of
> the code should be done
> in pure java - not in jelly with help of ant.
The following comment has been added to this issue:
Author: Martin Skopp
Created: Wed, 18 Jun 2003 5:15 AM
Body:
IMHO even if the snapshot exists in the remote repo, the freshest/newest should be
taken.
maven downloads snapshots from remote repo even if locally a fresher version e
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 11:20
> To: 'Maven Developers List'
> Subject: RE: Recent changes in war plugin
>
>
>
> > -Original Message-
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 18
The following issue has been updated:
Updater: Vincent Massol (mailto:[EMAIL PROTECTED])
Date: Wed, 18 Jun 2003 4:38 AM
Changes:
Version changed from to 1.0-beta-10
Fix Version changed from to 1.0-beta-10
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-495
Here is an overview of the issue:
--
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2003 10:33 AM
> To: 'Maven Developers List'
> Subject: RE: Recent changes in war plugin
>
>
>
> > -Original Message-
> > From: Michal Maczka [mailto:[EMAIL PROTECTED]
> > Sent: 18
> -Original Message-
> From: Michal Maczka [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2003 10:01
> To: 'Maven Developers List'
> Subject: RE: Recent changes in war plugin
>
> Yes.
> I am still working on deployer.
> That's the art which I want to use in this plugin to add missing
> functi
Michal Maczka wrote:
> Does anybody has something against building war ___always__ in two distinct
> steps?
>
> a) copying to build area (somewhere in target/ )
> b) making a jar archive
Go for it - it seems to simplify things, and people might want to run
their application off that "explode
Yes.
I am still working on deployer.
That's the art which I want to use in this plugin to add missing
functionality.
Once I am readay with this for war plugin, I am planning to change also
other plugins.
Last time I am asking:
Does anybody has something against building war ___always__ in two
dion2003/06/18 00:19:02
Modified:xdocsnavigation.xml
Log:
- Move web stats and wiki to new Apache Menu
- Add Apache Developer resources link
Revision ChangesPath
1.20 +4 -1 maven/xdocs/navigation.xml
Index: navigation.xml
===
50 matches
Mail list logo
