Re: JIRA projects for m2 plugins?
My vote: create a new project for every m2 plugin. That said, I think it would be great to have a separate machine for that. Stéphane On 11/15/05, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > I think we should vote to solve this asap, I believe these are the > options: > > [ ] create a new project for new m2 plugins, reuse m1 projects adding > a new version > [ ] create a new project for every m2 plugin > [ ] keep it as it's now > > On 11/15/05, Vincent Massol <[EMAIL PROTECTED]> wrote: > > So what's the status on this? > > > > - Have we decided to create separate JIRA projects for m2 plugins? > > - Can I create a Clover JIRA project the m2 clover plugin? I'd like to > get > > moving on this. > > - Is there any recommendation for versioning the plugins? Should we > start at > > 2.0 and simply increase the minor? Do plugins have to go through alphas, > > betas, rcs or is it left at the discretion of the plugin contributors in > > general? > > > > Thanks > > -Vincent > > > > > > - > > 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] > > -- .::You're welcome ::.
Re: JIRA projects for m2 plugins?
My vote > [x] create a new project for new m2 plugins, reuse m1 projects adding > a new version > [ ] create a new project for every m2 plugin > [ ] keep it as it's now > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JIRA projects for m2 plugins?
> -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: mercredi 16 novembre 2005 01:04 > To: Maven Developers List > Subject: Re: JIRA projects for m2 plugins? > > On Tue, 2005-11-15 at 12:27 -0800, Carlos Sanchez wrote: > > I think we should vote to solve this asap, I believe these are the > options: > > > > [ ] create a new project for new m2 plugins, reuse m1 projects adding > > a new version > > [ ] create a new project for every m2 plugin > > +1 +1 too > > [ ] keep it as it's now > > There is a good citizen aspect of this to consider. We'll flood the > dashboard if we do this. Ideally I think a dedicated machine would be > best and I think this can be done in a relatively short period of time. > > Vincent, will what we have now not work for you using a component? What we have now is a single Maven 2 project with components. So we're already using JIRA components. Not sure what you mean. > Also, I have fully automated manipulating JIRA via SOAP and I can create > new projects quickly using that. So I can make all the projects once we > decide what we're going to do. That's very cool. Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Snapshots and version resolution
Brett,
There was a bug in the deploy code that has been fixed by John. The
${version} expression in deps wasn't getting resolved at deploy time.
Thanks
-Vincent
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: mercredi 16 novembre 2005 01:08
> To: Maven Developers List
> Subject: Re: Snapshots and version resolution
>
> You have to have that locally, I presume it was a failed deploy attempt
> in which case we need to improve the point at which the data is written.
>
> Look in your local repository for where the value comes from.
>
> - Brett
>
> Vincent Massol wrote:
> > Hi,
> >
> > I have uploaded the cargo m2 plugin to a private repo and I'm trying to
> use
> > it from a m2 project. All the cargo artifacts that I have uploaded are
> > snapshots. They all have a different resolved timestamp.
> >
> > However when I run the cargo m2 plugin on my m2 project m2 looks for a
> an
> > artifact (cargo-core-generic) with the resolved timestamp version of the
> > cargo m2 plugin (20051115.115553-2 as shown on
> > http://cargo.codehaus.org/dist2/org/codehaus/cargo/maven2/cargo-maven2-
> plugi
> > n/0.7-SNAPSHOT/).
> >
> > Of course this version is not found for the cargo-core-generic artifact:
> > http://cargo.codehaus.org/dist2/org/codehaus/cargo/core/cargo-core-
> generic/0
> > .7-SNAPSHOT/
> >
> > Is that a bug?
> >
> > Thanks
> > -Vincent
> >
> >
> > -
> > 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]
RE: svn commit: r344386 - /maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java
Thanks John for the feedback.
I still have trouble understanding what's the difference between a deploy
and a release and I would think we'd need to merge both concept into one in
the future.
If you think about it, the result of both actions is the same from a user
point of view. The only differences are the extra steps during a release but
we could decide not to take those extra steps (tagging, sending an email,
etc) when we release a snapshot.
To summarize, I think having a single concept of release (or deploy) would
be enough and it should cover both snapshot and proper versions.
-Vincent
> -Original Message-
> From: John Casey [mailto:[EMAIL PROTECTED]
> Sent: mercredi 16 novembre 2005 04:00
> To: Maven Developers List
> Subject: Re: svn commit: r344386 - /maven/components/trunk/maven-
> project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
> adata.java
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> deployment doesn't guarantee reproducibility. I already discussed this
> with you on IRC, but I'm replicating my answer here to keep the list up
> to date.
>
> The only time you have strong requirements for reproducibility in builds
> is at release time, when all -SNAPSHOT dependencies should already have
> been resolved to concrete versions (even if these versions are the
> timestamped alter egos of the snapshot artifacts). When you're merely
> deploying, you're not making any assertion about the build being
> static...particularly when you deploy with SNAPSHOT dependencies. In
> those cases, it's important that your artifact's users be able to retain
> that flexibility in choosing dependency versions given by SNAPSHOTs.
>
> Deploying is still a distinct task from releasing, since you may deploy
> a snapshot artifact in order to share it among team members, or CI
> servers, without releasing it. In this case, it's understood that this
> is a development copy, and you get what you ask for with any SNAPSHOT
> dependencies. That is, dynamically resolved versions...even dynamically
> re-resolved versions, if the artifact is used more than once over time.
>
> Cheers,
>
> John
>
> Vincent Massol wrote:
> | Thanks John,
> |
> | When I deploy now the resolved version is 0.7-SNASPHOT and not the
> | timestamped version.
> |
> | It may work but that means that builds will not be reproducible,
> because the
> | correct dependency version will be chosen at runtime according to the
> | available snapshots, right?
> |
> | Thanks
> | -Vincent
> |
> |
> |>-Original Message-
> |>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> |>Sent: mardi 15 novembre 2005 17:15
> |>To: commits@maven.apache.org
> |>Subject: svn commit: r344386 - /maven/components/trunk/maven-
> |>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactM
> et
> |>adata.java
> |>
> |>Author: jdcasey
> |>Date: Tue Nov 15 08:15:21 2005
> |>New Revision: 344386
> |>
> |>URL: http://svn.apache.org/viewcvs?rev=344386&view=rev
> |>Log:
> |>Decoupling ${version} expressions from POM version before resolving it
> to
> |>a buildnumber/timestamp on install or deploy.
> |>
> |>Modified:
> |>maven/components/trunk/maven-
> |>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactM
> et
> |>adata.java
> |>
> |>Modified: maven/components/trunk/maven-
> |>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactM
> et
> |>adata.java
> |>URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-
> |>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactM
> et
> |>adata.java?rev=344386&r1=344385&r2=344386&view=diff
> |>
> ==
> |>
> |>--- maven/components/trunk/maven-
> |>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactM
> et
> |>adata.java (original)
> |>+++ maven/components/trunk/maven-
> |>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactM
> et
> |>adata.java Tue Nov 15 08:15:21 2005
> |>@@ -34,6 +34,8 @@
> |> import java.io.FileReader;
> |> import java.io.FileWriter;
> |> import java.io.IOException;
> |>+import java.io.StringReader;
> |>+import java.io.StringWriter;
> |>
> |> /**
> |> * Attach a POM to an artifact.
> |>@@ -85,10 +87,17 @@
> |> try
> |> {
> |> reader = new FileReader( file );
> |>+StringWriter sWriter = new StringWriter();
> |>+IOUtil.copy( reader, sWriter );
> |>+
> |>+String modelSrc = sWriter.toString().replaceAll(
> |>"\\$\\{(pom\\.|project\\.)?version\\}", artifact.getBaseVersion() );
> |>+
> |>+StringReader sReader = new StringReader( modelSrc );
> |>+
> |> writer = new FileWriter( destination );
> |>
> |> MavenXpp3Reader modelReader = new MavenXpp3Reader();
> |>-Model model = modelReader.read( reader );
> |>+Model model = modelReader.read( sReader );
> |> model.set
[maven2 build - SUCCESS - update] Wed Nov 16 06:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051116.06.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051116.06.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1560) Guide to accessing repository with https client authentication
[ http://jira.codehaus.org/browse/MNG-1560?page=all ] Edwin Punzalan updated MNG-1560: Fix Version: (was: 2.0) 2.0.1 > Guide to accessing repository with https client authentication > -- > > Key: MNG-1560 > URL: http://jira.codehaus.org/browse/MNG-1560 > Project: Maven 2 > Type: Improvement > Components: documentation - guides > Versions: 2.0 > Reporter: Arnaud Bailly > Priority: Minor > Fix For: 2.0.1 > Attachments: MavenRepoSSLAccess.apt > > > The attachment describes a way (in APT format) to use a remote repository > through HTTPS with client-side certificate authentication. This may be useful > in corporate or private development settings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-197) Improvements for Commons Chain pom
[ http://jira.codehaus.org/browse/MEV-197?page=comments#action_51081 ] Carlos Sanchez commented on MEV-197: I don't know, you're the one working with commons-chain ;) You can ask in their mailing list > Improvements for Commons Chain pom > -- > > Key: MEV-197 > URL: http://jira.codehaus.org/browse/MEV-197 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: Wendy Smoak > Assignee: Edwin Punzalan > Attachments: chain-1.0-20051115.diff > > > Making some dependencies optional, changing to standard groupId for Sun jars -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-197) Improvements for Commons Chain pom
[ http://jira.codehaus.org/browse/MEV-197?page=comments#action_51080 ] Wendy Smoak commented on MEV-197: - Then shouldn't Portlet also be 'provided'? I don't do portlets, but I assume the api is provided by the Portal. (I need to know in order to patch the Chain m1 build file, so it will be converted correctly in the future.) > Improvements for Commons Chain pom > -- > > Key: MEV-197 > URL: http://jira.codehaus.org/browse/MEV-197 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: Wendy Smoak > Assignee: Edwin Punzalan > Attachments: chain-1.0-20051115.diff > > > Making some dependencies optional, changing to standard groupId for Sun jars -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Wed Nov 16 04:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051116.041500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051116.041500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Wed Nov 16 03:45:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051116.034500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051116.034500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Wed Nov 16 03:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051116.033000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051116.033000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1585) debug logging from wagon not shown in debug mode
[ http://jira.codehaus.org/browse/MNG-1585?page=comments#action_51078 ] John Casey commented on MNG-1585: - is this related to MNG-1501? > debug logging from wagon not shown in debug mode > > > Key: MNG-1585 > URL: http://jira.codehaus.org/browse/MNG-1585 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Reporter: Brett Porter > Fix For: 2.0.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: continuum lock issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think Emmanuel was able to get around this issue using READ_UNCOMMITTED in the jpox config properties, but it definitely needs some testing. - -j Brett Porter wrote: | Hi, | | I found that adding plexus' root pom.xml on a clean continuum install | (latest build on the zone) and then running "build all" exhibits the | locking issues - if that helps in being able to reproduce it? | | - Brett | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDeqGfK3h2CZwO/4URAvKVAJwNT9mYCFZ2/SQxPCPm78o6tePHDgCdEsb2 fuBHEDnePG+dSDM0zlGlqnY= =zNdO -END PGP SIGNATURE-
Re: svn commit: r344256 - in /maven/components/trunk/maven-plugins: maven-assembly-plugin/pom.xml pom.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You're right, as usual. I've rolled back this change for the assembly plugin, and avoided using the 2.0.1 API in the assembly plugin patches I applied today, in order to release the new version of the assembly plugin ahead of the 2.0.1 release. Brett Porter wrote: | If you are referencing the new API, then this will be 2.0.1. Is that | really what you want - ie is there no way around it? | | If not, then you need to add the tag or there'll be some | unhappy 2.0 users when it gets released. | | - Brett | | [EMAIL PROTECTED] wrote: | |> Author: jdcasey |> Date: Mon Nov 14 14:52:06 2005 |> New Revision: 344256 |> |> URL: http://svn.apache.org/viewcvs?rev=344256&view=rev |> Log: |> Bumping Plugin-Parent version to 2.0.1-SNAPSHOT to reference API |> changes to MavenProjectHelper, and changing maven-assembly-plugin's |> pom to reference that new parent POM. |> |> Modified: |> maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml |> maven/components/trunk/maven-plugins/pom.xml |> |> Modified: |> maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml |> URL: |> http://svn.apache.org/viewcvs/maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml?rev=344256&r1=344255&r2=344256&view=diff |> |> == |> |> --- maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml |> (original) |> +++ maven/components/trunk/maven-plugins/maven-assembly-plugin/pom.xml |> Mon Nov 14 14:52:06 2005 |> @@ -2,7 +2,7 @@ |> |> maven-plugin-parent |> org.apache.maven.plugins |> -2.0 |> +2.0.1-SNAPSHOT |> |>4.0.0 |>maven-assembly-plugin |> |> Modified: maven/components/trunk/maven-plugins/pom.xml |> URL: |> http://svn.apache.org/viewcvs/maven/components/trunk/maven-plugins/pom.xml?rev=344256&r1=344255&r2=344256&view=diff |> |> == |> |> --- maven/components/trunk/maven-plugins/pom.xml (original) |> +++ maven/components/trunk/maven-plugins/pom.xml Mon Nov 14 14:52:06 2005 |> @@ -150,7 +150,7 @@ |> |> org.apache.maven |> maven-project |> -2.0 |> +2.0.1-SNAPSHOT |> |> |> org.codehaus.plexus |> |> | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDeqFoK3h2CZwO/4URArubAJ945gqC+B7RBaf3UzQHpUux3oYs6ACggWKE IWRWO+dV4tC9N1wbQmtsroQ= =fxS+ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r344386 - /maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
deployment doesn't guarantee reproducibility. I already discussed this
with you on IRC, but I'm replicating my answer here to keep the list up
to date.
The only time you have strong requirements for reproducibility in builds
is at release time, when all -SNAPSHOT dependencies should already have
been resolved to concrete versions (even if these versions are the
timestamped alter egos of the snapshot artifacts). When you're merely
deploying, you're not making any assertion about the build being
static...particularly when you deploy with SNAPSHOT dependencies. In
those cases, it's important that your artifact's users be able to retain
that flexibility in choosing dependency versions given by SNAPSHOTs.
Deploying is still a distinct task from releasing, since you may deploy
a snapshot artifact in order to share it among team members, or CI
servers, without releasing it. In this case, it's understood that this
is a development copy, and you get what you ask for with any SNAPSHOT
dependencies. That is, dynamically resolved versions...even dynamically
re-resolved versions, if the artifact is used more than once over time.
Cheers,
John
Vincent Massol wrote:
| Thanks John,
|
| When I deploy now the resolved version is 0.7-SNASPHOT and not the
| timestamped version.
|
| It may work but that means that builds will not be reproducible,
because the
| correct dependency version will be chosen at runtime according to the
| available snapshots, right?
|
| Thanks
| -Vincent
|
|
|>-Original Message-
|>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
|>Sent: mardi 15 novembre 2005 17:15
|>To: commits@maven.apache.org
|>Subject: svn commit: r344386 - /maven/components/trunk/maven-
|>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
|>adata.java
|>
|>Author: jdcasey
|>Date: Tue Nov 15 08:15:21 2005
|>New Revision: 344386
|>
|>URL: http://svn.apache.org/viewcvs?rev=344386&view=rev
|>Log:
|>Decoupling ${version} expressions from POM version before resolving it to
|>a buildnumber/timestamp on install or deploy.
|>
|>Modified:
|>maven/components/trunk/maven-
|>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
|>adata.java
|>
|>Modified: maven/components/trunk/maven-
|>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
|>adata.java
|>URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-
|>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
|>adata.java?rev=344386&r1=344385&r2=344386&view=diff
|>==
|>
|>--- maven/components/trunk/maven-
|>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
|>adata.java (original)
|>+++ maven/components/trunk/maven-
|>project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
|>adata.java Tue Nov 15 08:15:21 2005
|>@@ -34,6 +34,8 @@
|> import java.io.FileReader;
|> import java.io.FileWriter;
|> import java.io.IOException;
|>+import java.io.StringReader;
|>+import java.io.StringWriter;
|>
|> /**
|> * Attach a POM to an artifact.
|>@@ -85,10 +87,17 @@
|> try
|> {
|> reader = new FileReader( file );
|>+StringWriter sWriter = new StringWriter();
|>+IOUtil.copy( reader, sWriter );
|>+
|>+String modelSrc = sWriter.toString().replaceAll(
|>"\\$\\{(pom\\.|project\\.)?version\\}", artifact.getBaseVersion() );
|>+
|>+StringReader sReader = new StringReader( modelSrc );
|>+
|> writer = new FileWriter( destination );
|>
|> MavenXpp3Reader modelReader = new MavenXpp3Reader();
|>-Model model = modelReader.read( reader );
|>+Model model = modelReader.read( sReader );
|> model.setVersion( artifact.getVersion() );
|>
|> DistributionManagement distributionManagement =
|>model.getDistributionManagement();
|>
|
|
|
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDeqCoK3h2CZwO/4URApqhAJ9NwzHOaIwADvzlN2/g0IukdrAtjACfTWQS
kq2UVxAkkKiKKrXfBkMaF44=
=LXVp
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA projects for m2 plugins?
On Tue, 2005-11-15 at 12:27 -0800, Carlos Sanchez wrote: > I think we should vote to solve this asap, I believe these are the options: > > [ ] create a new project for new m2 plugins, reuse m1 projects adding > a new version > [ ] create a new project for every m2 plugin +1 > [ ] keep it as it's now There is a good citizen aspect of this to consider. We'll flood the dashboard if we do this. Ideally I think a dedicated machine would be best and I think this can be done in a relatively short period of time. Vincent, will what we have now not work for you using a component? Also, I have fully automated manipulating JIRA via SOAP and I can create new projects quickly using that. So I can make all the projects once we decide what we're going to do. -- 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]
[jira] Closed: (MEV-3) Broken dependencies for nanocontainer
[ http://jira.codehaus.org/browse/MEV-3?page=all ]
Edwin Punzalan closed MEV-3:
Resolution: Fixed
Fixed.
NOTE: May take up to 4 hours to reach central repo.
> Broken dependencies for nanocontainer
> -
>
> Key: MEV-3
> URL: http://jira.codehaus.org/browse/MEV-3
> Project: Maven Evangelism
> Type: Task
> Reporter: Mark Hobson
> Assignee: Edwin Punzalan
>
>
> Broken dependencies for:
> http://www.ibiblio.org/maven2/nanocontainer/nanocontainer/1.0-beta-4/nanocontainer-1.0-beta-4.pom
> Dependencies use jelly variables ${picocontainer.version} and
> ${pom.currentVersion}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/15-Nov-2005_08.33.44/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-126) poms for som emissing sun xml API + javamail 1.3.3
[ http://jira.codehaus.org/browse/MEV-126?page=all ] Edwin Punzalan closed MEV-126: -- Resolution: Fixed I'm closing this issue as the poms from ibiblio are already updated. > poms for som emissing sun xml API + javamail 1.3.3 > -- > > Key: MEV-126 > URL: http://jira.codehaus.org/browse/MEV-126 > Project: Maven Evangelism > Type: Improvement > Components: Missing POM > Reporter: nicolas de loof > Assignee: Edwin Punzalan > Attachments: javax-poms.zip, javax.zip, merged-proposals.zip, xml.zip, > xml.zip > > > javax.xml.jaxm (1.1) > javax.xml.jaxp (1.3) > javax.xml.jax-qname (1.1) > javax.xml.jaxr (1.0) > javax.xml.saaj (1.2) > javax.mail (1.3.3) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-451) jabber doesn't work with talk.google.com
jabber doesn't work with talk.google.com Key: CONTINUUM-451 URL: http://jira.codehaus.org/browse/CONTINUUM-451 Project: Continuum Type: Task Reporter: Brett Porter Fix For: 1.1 from what I can tell, talk.google.com is on port 5222, but still SSL. However, selecting port 5222 and trying SSL conects on 5223, which gives an exception that there is no response. @4000437a7d6d2975942c Caused by: org.codehaus.plexus.jabber.JabberClientException: Can't connect to talk.google.com:5223 @4000437a7d6d29759bfc at org.codehaus.plexus.jabber.DefaultJabberClient.connect(DefaultJabberClient.java:51) @4000437a7d6d2975a3cc at org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:207) @4000437a7d6d2975c30c ... 7 more @4000437a7d6d2975c6f4 Caused by: Connection failed. No response from server.: @4000437a7d6d2975cadc at org.jivesoftware.smack.PacketReader.startup(PacketReader.java:170) @4000437a7d6d2975d2ac at org.jivesoftware.smack.XMPPConnection.init(XMPPConnection.java:766) @4000437a7d6d2975d694 at org.jivesoftware.smack.XMPPConnection.(XMPPConnection.java:222) @4000437a7d6d2975f5d4 at org.jivesoftware.smack.SSLXMPPConnection.(SSLXMPPConnection.java:87) @4000437a7d6d2975fda4 at org.codehaus.plexus.jabber.DefaultJabberClient.connect(DefaultJabberClient.java:46) @4000437a7d6d29760574 ... 8 more Using no SSL gives: @4000437a771714668e9c Caused by: org.codehaus.plexus.jabber.JabberClientException: Can't connect to talk.gmail.com:5222 @4000437a77171466966c at org.codehaus.plexus.jabber.DefaultJabberClient.connect(DefaultJabberClient.java:51) @4000437a771714669e3c at org.apache.maven.continuum.notification.jabber.JabberContinuumNotifier.sendMessage(JabberContinuumNotifier.java:207) @4000437a77171466c164 ... 7 more @4000437a77171466c54c Caused by: Could not connect to talk.gmail.com:5222.: (504) @4000437a77171466c934 -- caused by: java.net.UnknownHostException: talk.gmail.com @4000437a77171466d104 at org.jivesoftware.smack.XMPPConnection.(XMPPConnection.java:168) @4000437a77171466d4ec at org.codehaus.plexus.jabber.DefaultJabberClient.connect(DefaultJabberClient.java:42) @4000437a77171466f42c ... 8 more Perhaps we can use Smack 2.0's special GoogleTalkConnection and add a new notifier type? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-1585) debug logging from wagon not shown in debug mode
debug logging from wagon not shown in debug mode Key: MNG-1585 URL: http://jira.codehaus.org/browse/MNG-1585 Project: Maven 2 Type: Bug Components: maven-artifact Reporter: Brett Porter Fix For: 2.0.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - checkout] Wed Nov 16 00:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051116.001500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051116.001500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Wed Nov 16 00:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051116.00.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051116.00.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r344377 - /maven/components/trunk/m2-bootstrap-all.bat
It need sto be fixed but is a low priority as it only affects biuld the plugin plugin after having built the plugin plugin with the bootstrap which is very specific to our environment. - Brett Vincent Massol wrote: -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: mardi 15 novembre 2005 17:31 To: dev@maven.apache.org Subject: Re: svn commit: r344377 - /maven/components/trunk/m2-bootstrap- all.bat It will be better to find and fix the pb in maven instead of this bootstrap script Obviously... Nobody is going to disagree with you on this... :-) BTW this is also true for the unix version. Do you have a patch? Right now this allows building on windows. This has been going on for weeks/months like this with a broken bootstrap. So, there's little change it's going to be fixed anytime soon if nobody works on it. At least now m2 can be built. Thanks -Vincent [EMAIL PROTECTED] a écrit : Author: vmassol Date: Tue Nov 15 07:37:46 2005 New Revision: 344377 URL: http://svn.apache.org/viewcvs?rev=344377&view=rev Log: Fixed bootstrap on windows. For some reason the plugin plugin doesn't build the first time so we need to build it twice... Modified: maven/components/trunk/m2-bootstrap-all.bat Modified: maven/components/trunk/m2-bootstrap-all.bat URL: http://svn.apache.org/viewcvs/maven/components/trunk/m2-bootstrap- all.bat?rev=344377&r1=344376&r2=344377&view=diff == --- maven/components/trunk/m2-bootstrap-all.bat (original) +++ maven/components/trunk/m2-bootstrap-all.bat Tue Nov 15 07:37:46 2005 @@ -120,6 +120,12 @@ echo -- - echo Rebuilding maven2 plugins echo -- - + [EMAIL PROTECTED] Build plugin plugin first, it seems to choke on the version built by the bootstrap +cd maven-plugins\maven-plugin-plugin +call mvn --no-plugin-registry --batch-mode --fail-at-end -e %MAVEN_CMD_LINE_ARGS% clean:clean install +cd ..\.. + cd maven-plugins @REM update the release info to ensure these versions get used in the integration tests call mvn --no-plugin-registry --batch-mode -DupdateReleaseInfo=true -e %MAVEN_CMD_LINE_ARGS% clean:clean install - 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]
Re: Snapshots and version resolution
You have to have that locally, I presume it was a failed deploy attempt in which case we need to improve the point at which the data is written. Look in your local repository for where the value comes from. - Brett Vincent Massol wrote: Hi, I have uploaded the cargo m2 plugin to a private repo and I'm trying to use it from a m2 project. All the cargo artifacts that I have uploaded are snapshots. They all have a different resolved timestamp. However when I run the cargo m2 plugin on my m2 project m2 looks for a an artifact (cargo-core-generic) with the resolved timestamp version of the cargo m2 plugin (20051115.115553-2 as shown on http://cargo.codehaus.org/dist2/org/codehaus/cargo/maven2/cargo-maven2-plugi n/0.7-SNAPSHOT/). Of course this version is not found for the cargo-core-generic artifact: http://cargo.codehaus.org/dist2/org/codehaus/cargo/core/cargo-core-generic/0 .7-SNAPSHOT/ Is that a bug? Thanks -Vincent - 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]
[jira] Commented: (MEV-190) Missing dependencies for slide-webdavlib
[ http://jira.codehaus.org/browse/MEV-190?page=comments#action_51053 ] Mark Hobson commented on MEV-190: - You mean on ibiblio? It's here: http://www.ibiblio.org/maven2/slide/slide-webdavlib/2.1/ Or if you mean the project, 2.1 is here: http://jakarta.apache.org/slide/download.html > Missing dependencies for slide-webdavlib > > > Key: MEV-190 > URL: http://jira.codehaus.org/browse/MEV-190 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: Mark Hobson > Assignee: Edwin Punzalan > > > Unsure who's responsible for this - apache projects are meant to be synced > with ibiblio and thus should be fixed at source, although the slide team have > ignored requests to do so: > http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev/200510.mbox/[EMAIL > PROTECTED] > The dependencies should be: > > > commons-httpclient > commons-httpclient > 2.0.2 > > > jdom > jdom > 1.0 > > > de.zeigermann.xml > xml-im-exporter > 1.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-190) Missing dependencies for slide-webdavlib
[ http://jira.codehaus.org/browse/MEV-190?page=comments#action_51052 ] Edwin Punzalan commented on MEV-190: Can't seem to find 2.1 version. Are you referring to 2.1M1 ? > Missing dependencies for slide-webdavlib > > > Key: MEV-190 > URL: http://jira.codehaus.org/browse/MEV-190 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: Mark Hobson > Assignee: Edwin Punzalan > > > Unsure who's responsible for this - apache projects are meant to be synced > with ibiblio and thus should be fixed at source, although the slide team have > ignored requests to do so: > http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev/200510.mbox/[EMAIL > PROTECTED] > The dependencies should be: > > > commons-httpclient > commons-httpclient > 2.0.2 > > > jdom > jdom > 1.0 > > > de.zeigermann.xml > xml-im-exporter > 1.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-194) cactus missing dependencies
[ http://jira.codehaus.org/browse/MEV-194?page=all ] Edwin Punzalan closed MEV-194: -- Resolution: Fixed Patch applied. Thanks. NOTE: May take up to 4hours for the fix to reach central repo. > cactus missing dependencies > --- > > Key: MEV-194 > URL: http://jira.codehaus.org/browse/MEV-194 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: Tomislav Stojcevich > Assignee: Edwin Punzalan > Attachments: cactus-13-1.7.1.pom.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-195) securityfilter missing dependencies
[ http://jira.codehaus.org/browse/MEV-195?page=all ] Edwin Punzalan closed MEV-195: -- Resolution: Fixed Applied. Thanks. NOTE: May take up to 4hours for the fix to reach central repo. > securityfilter missing dependencies > --- > > Key: MEV-195 > URL: http://jira.codehaus.org/browse/MEV-195 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: Tomislav Stojcevich > Assignee: Edwin Punzalan > Attachments: securityfilter-2.0.pom.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1584) add google analytics code to website
add google analytics code to website Key: MNG-1584 URL: http://jira.codehaus.org/browse/MNG-1584 Project: Maven 2 Type: Task Components: documentation - general Reporter: Brett Porter Assigned to: Brett Porter I've created an account. It seems to be ok in terms and conditions, and might help us figure out the effectiveness of our docs. Worth a try. http://www.google-analytics.com/urchin.js"; type="text/javascript"> _uacct = "UA-140879-1"; urchinTracker(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1583) Give pointers to integration tests in the docs
Give pointers to integration tests in the docs -- Key: MNG-1583 URL: http://jira.codehaus.org/browse/MNG-1583 Project: Maven 2 Type: Improvement Components: documentation - guides Versions: 2.0 Reporter: Carlos Sanchez Experimented developers like looking at code, so let's give them pointers from the guides to the integration tests where the features are used as example -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1582) Add how to convert pregoals and postgoals to lifecycle to the m1-m2 guide
Add how to convert pregoals and postgoals to lifecycle to the m1-m2 guide - Key: MNG-1582 URL: http://jira.codehaus.org/browse/MNG-1582 Project: Maven 2 Type: Improvement Components: documentation - guides Versions: 2.0 Reporter: Carlos Sanchez guide to convert pregoals and postgoals to lifecycle give a pointer to the integration test that covers lifecycle as a example -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 22:45:01 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.224501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPDIST-28) Allow to configure to which files should use CRLF line endings in Zip archives
Allow to configure to which files should use CRLF line endings in Zip archives -- Key: MPDIST-28 URL: http://jira.codehaus.org/browse/MPDIST-28 Project: maven-dist-plugin Type: Improvement Versions: 1.7 Environment: 1.7 Reporter: Arnaud Heritier Fix For: 1.7 Add a new property to replace the hardcoded filter **/*.txt used in fixcrlf tasks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 22:30:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.223001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-450) Publish the build results to a different machine
Publish the build results to a different machine Key: CONTINUUM-450 URL: http://jira.codehaus.org/browse/CONTINUUM-450 Project: Continuum Type: New Feature Versions: 1.0 Reporter: Carlos Sanchez The build machine won't be usually available to other people, so do something to publish the build results to a machine that it is available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-1581) Make sure that there aren't two jars with the same artifactId and version
Make sure that there aren't two jars with the same artifactId and version - Key: MNG-1581 URL: http://jira.codehaus.org/browse/MNG-1581 Project: Maven 2 Type: Improvement Components: maven-war-plugin Versions: 2.0 Reporter: Carlos Sanchez Priority: Trivial make sure that there aren't two jars with the same artifactId and version (which would overwrite one to the other in the WEB-INF/lib folder). In that case the groupId could be added to the start of the name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 22:15:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.221500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-207) Hibernate 3.1rc2 missing jar
[ http://jira.codehaus.org/browse/MEV-207?page=all ] Carlos Sanchez closed MEV-207: -- Assign To: Carlos Sanchez Resolution: Fixed > Hibernate 3.1rc2 missing jar > > > Key: MEV-207 > URL: http://jira.codehaus.org/browse/MEV-207 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: mike perham > Assignee: Carlos Sanchez > > > It looks like the jar didn't make the move with the POM when moving from > hibernate:hibernate to org.hibernate:hibernate. Please copy the jar from the > old location at hibernate/hibernate/3.1rc2 to org/hibernate/hibernate/3.1rc2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-449) title bar says "Jabber" when creating an MSN notifier
title bar says "Jabber" when creating an MSN notifier - Key: CONTINUUM-449 URL: http://jira.codehaus.org/browse/CONTINUUM-449 Project: Continuum Type: Bug Reporter: Brett Porter Priority: Trivial Fix For: 1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-1580) Unable to enable http-wagon instead of http-wagon-lightweight using
Unable to enable http-wagon instead of http-wagon-lightweight using --- Key: MNG-1580 URL: http://jira.codehaus.org/browse/MNG-1580 Project: Maven 2 Type: Bug Versions: 2.0 Environment: CentOS release 4.1 (Final) Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Reporter: David Rice I am attempting to deploy using http and in order to use the http-wagon plugin I had to remove the wagon-http-lightweight-1.0-alpha-5.jar jar from the lib directory and put in the wagon-http-1.0-alpha-5.jar. I attempted to refer to the wagon-http in the section. It downloaded the plugin, but continued to get the error "PUT operation is not supported by Light Weight HTTP wagon". Only removing the lightweight jar fixed this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-448) imrpvoe performance of "show projects" page
imrpvoe performance of "show projects" page --- Key: CONTINUUM-448 URL: http://jira.codehaus.org/browse/CONTINUUM-448 Project: Continuum Type: Improvement Reporter: Brett Porter Fix For: 1.1 this seems to reload all the projects and a bunch of objects underneath - even with just the plexus projects in there it becomes very slow. Check fetch groups and maybe add caching. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-28) bogus dependencies in commons-configuration
[ http://jira.codehaus.org/browse/MEV-28?page=all ] Carlos Sanchez closed MEV-28: - Assign To: Carlos Sanchez Resolution: Fixed Fixed in svn repo > bogus dependencies in commons-configuration > --- > > Key: MEV-28 > URL: http://jira.codehaus.org/browse/MEV-28 > Project: Maven Evangelism > Type: Task > Components: Dependencies > Reporter: Brett Porter > Assignee: Carlos Sanchez > > > as previously sent to commons-dev: > There are a few suspect dependencies in the POM from the 1.1 release: > - - resources:resources:1.0 doesn't exist - how does Maven build with this? > - - as of commons-logging 1.0.4, I believe you should be dependening on > commons-logging-api? > - - dependency on dbunit, which is LGPL (Eric Pugh is a committer on > both - perhaps he could propose a change to ASL/BSD?) > - - badly specified mockobjects IDs (I thought the old format used + > instead of :, but regardless - you should split it to group/artifactId > - - dependency on findbugs, which is LGPL. (The plugin being used is > ASL, but findbugs is LGPL) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 21:45:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.214500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 21:30:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.213000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 21:15:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.211501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 21:00:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.210001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-207) Hibernate 3.1rc2 missing jar
Hibernate 3.1rc2 missing jar Key: MEV-207 URL: http://jira.codehaus.org/browse/MEV-207 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: mike perham It looks like the jar didn't make the move with the POM when moving from hibernate:hibernate to org.hibernate:hibernate. Please copy the jar from the old location at hibernate/hibernate/3.1rc2 to org/hibernate/hibernate/3.1rc2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 20:45:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.204500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 20:30:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.203001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA projects for m2 plugins?
I think we should vote to solve this asap, I believe these are the options: [ ] create a new project for new m2 plugins, reuse m1 projects adding a new version [ ] create a new project for every m2 plugin [ ] keep it as it's now On 11/15/05, Vincent Massol <[EMAIL PROTECTED]> wrote: > So what's the status on this? > > - Have we decided to create separate JIRA projects for m2 plugins? > - Can I create a Clover JIRA project the m2 clover plugin? I'd like to get > moving on this. > - Is there any recommendation for versioning the plugins? Should we start at > 2.0 and simply increase the minor? Do plugins have to go through alphas, > betas, rcs or is it left at the discretion of the plugin contributors in > general? > > Thanks > -Vincent > > > - > 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]
[maven2 build - FAILED - update] Tue Nov 15 20:00:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.20.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1462) assembly:assembly forks a lifecycle and cannot be used in a reactor environment. Need a new mojo suitable for this environment,
[ http://jira.codehaus.org/browse/MNG-1462?page=all ]
John Casey closed MNG-1462:
---
Resolution: Fixed
applied. Thanks, Jerome.
> assembly:assembly forks a lifecycle and cannot be used in a reactor
> environment. Need a new mojo suitable for this environment,
> ---
>
> Key: MNG-1462
> URL: http://jira.codehaus.org/browse/MNG-1462
> Project: Maven 2
> Type: Improvement
> Components: maven-assembly-plugin
> Versions: 2.0
> Reporter: Jerome Lacoste
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.1
> Attachments: MNG-1462-attached_mojo_for_assembly_plugin.diff
>
> Original Estimate: 30 minutes
> Remaining: 30 minutes
>
> Basically I use the assembly plugin in a module under the reactor project.
> I attach the assembly plugin to the verify phase (because of MNG-1311), but
> somehow when my module is being processed, the plugin is executed for the
> package phase and it
> forks the full project lifecycle, because it is an aggregator.
> This triggers the rebuild all my reactor projects.
>
> This happens twice (I have 2 modules which use the assembly plugin),
> making my build 3 times too long.
>
>
>
> Now investigating the issue.
>
> The stack trace looks like:
>
> private void executeGoalAndHandleFailures( String task, MavenSession session,
> MavenProject project,
>EventDispatcher dispatcher, String
> event, ReactorManager rm,
>long buildStartTime, String target
> )
>
> private void executeGoal( String task, MavenSession session, MavenProject
> project )
>
> private void executeGoalWithLifecycle( String task, MavenSession session, Map
> lifecycleMappings,
>MavenProject project, Lifecycle
> lifecycle )
>
> private void executeGoals( List goals, MavenSession session, MavenProject
> project )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
>
> private void forkLifecycle( MojoDescriptor mojoDescriptor, MavenSession
> session, MavenProject project )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
>
> which creates the redundancy here:
>
> private void forkLifecycle( MojoDescriptor mojoDescriptor, MavenSession
> session, MavenProject project )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
> {
> PluginDescriptor pluginDescriptor =
> mojoDescriptor.getPluginDescriptor();
> getLogger().info( "Preparing " + pluginDescriptor.getGoalPrefix() +
> ":" + mojoDescriptor.getGoal() );
>
> if ( mojoDescriptor.isAggregator() )
> {
> for ( Iterator i = session.getSortedProjects().iterator();
> i.hasNext(); )
> {
> MavenProject reactorProject = (MavenProject) i.next();
>
> line();
>
> getLogger().info( "Building " + reactorProject.getName() );
>
> line();
>
> forkProjectLifecycle( mojoDescriptor, session, reactorProject
> );
> }
> }
> else
> {
> forkProjectLifecycle( mojoDescriptor, session, project );
> }
> }
>
>
> The redundancy appears because the assembly plugin is an aggregator so if
> forked it will fork all reactor projects.
>
> It is forked in my case because the execute phase is not null.
>
> In DefaultLifeCycleExecutor:
>
> private void executeGoals( List goals, MavenSession session, MavenProject
> project )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
> {
> for ( Iterator i = goals.iterator(); i.hasNext(); )
> {
> MojoExecution mojoExecution = (MojoExecution) i.next();
>
> MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
>
> if ( mojoDescriptor.getExecutePhase() != null ||
> mojoDescriptor.getExecuteGoal() != null )
> {
> forkLifecycle( mojoDescriptor, session, project );
> }
>
>
> and getExecutePhase() is "package"
>
> Now before executing this:
>
> Map lifecycleMappings = constructLifecycleMappings( session,
> task, project, lifecycle );
> executeGoalWithLifecycle( task, session, lifecycleMappings,
> project, lifecycle );
>
>
> my lifecycleMappings contains 3 entries each with a list of single
> MojoExecution instances
>
> install -> ME21
> verify -> MJ17
> test -> MJ20
>
>
> Then when this mappings are processed as a goal chain:
>
> List goals = processGoalChain( task, lifecycleMappings, lifecycle );
>
> The goals have been
[jira] Updated: (MEV-197) Improvements for Commons Chain pom
[ http://jira.codehaus.org/browse/MEV-197?page=all ] Carlos Sanchez updated MEV-197: --- Attachment: (was: chain-1.0.diff) > Improvements for Commons Chain pom > -- > > Key: MEV-197 > URL: http://jira.codehaus.org/browse/MEV-197 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: Wendy Smoak > Attachments: chain-1.0-20051115.diff > > > Making some dependencies optional, changing to standard groupId for Sun jars -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-197) Improvements for Commons Chain pom
[ http://jira.codehaus.org/browse/MEV-197?page=all ] Carlos Sanchez updated MEV-197: --- Attachment: (was: chain-1.0.diff) > Improvements for Commons Chain pom > -- > > Key: MEV-197 > URL: http://jira.codehaus.org/browse/MEV-197 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: Wendy Smoak > Attachments: chain-1.0-20051115.diff > > > Making some dependencies optional, changing to standard groupId for Sun jars -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-157) Invalid deps in the dumbster pom
[ http://jira.codehaus.org/browse/MEV-157?page=comments#action_51036 ] Carlos Sanchez commented on MEV-157: Ok, I see, I thought these were relocated. Let's create reloaction poms for these two > Invalid deps in the dumbster pom > - > > Key: MEV-157 > URL: http://jira.codehaus.org/browse/MEV-157 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: Matt Todd > Assignee: Carlos Sanchez > > > > > activation > activation > 1.0.2 > > > javamail > mail > 1.3.2 > > > Should be: > > > javax.activation > activation > 1.0.2 > > > javax.mail > mail > 1.3.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1311) Cannot be executed in package phase (infinite loop when @execute is specified)
[ http://jira.codehaus.org/browse/MNG-1311?page=all ] John Casey updated MNG-1311: Assign To: John Casey Component: (was: maven-assembly-plugin) maven-core Complexity: Expert (was: Intermediate) Remaining Estimate: 2 hours Original Estimate: 2 hours Summary: Cannot be executed in package phase (infinite loop when @execute is specified) (was: Cannot be executed in package phase) need to track the entry point into a forked lifecycle, and remove the accumulated chain of entry points from each successive forked lifecycle. > Cannot be executed in package phase (infinite loop when @execute is specified) > -- > > Key: MNG-1311 > URL: http://jira.codehaus.org/browse/MNG-1311 > Project: Maven 2 > Type: Bug > Components: maven-core > Versions: 2.0 > Reporter: Jerome Lacoste > Assignee: John Casey > Fix For: 2.0.1 > > Original Estimate: 2 hours > Remaining: 2 hours > > If you run the assembly plugin in an execution for a phase (like package), it > goes into an endless loop. I am using the verify phase as the work-around. > Encountered by Jeff G, Philipp M and me :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1274) maven-assembly doesn't support war format
[ http://jira.codehaus.org/browse/MNG-1274?page=all ]
John Casey updated MNG-1274:
Description:
Trying to use the assembly plugin to repackage a war, I got the exception
below. The functionality was needed to implemented multi-webstart application
deployment in relation to the Webstart Plugin [1]
It fails miserably because of the missing webxml attribute required by the
WebArchiver, triggered because the specified format is war.
I was told on #maven that the assembly is not meant to package war. I don't see
why it couldn't :) So I mailed on @users [2]. Someone also asked for similar
funcionality [3].
So repackaging a war is clearly an required functionality.
Should we consider the assembly plugin one way to implement this feature, and
this is issue is indeed real?
Or should I take another approach, like move the assembly plugin execution as
part of an earlier phase (e.g. process-resources) inside the war project ?
Some links
Links:
[1] http://docs.codehaus.org/display/MOJO/Webstart+Plugin
[2] http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/29177
[3] http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/29243
Here's my assmbly descriptor:
main
war
false
/
myproject:webapp
true
runtime
webstart
myproject:webstart1
true
runtime
and here's a part of the pom
myproject
webapp
${version}
war
myproject
webstart1
${version}
zip
Here's the log:
[DEBUG] -- end configuration --
[INFO] [assembly:assembly]
[...]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error creating assembly: webxml attribute is required
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error creating
assembly: webxml attribute is required
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:214)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error
creating assembly: webxml attribute is required
at
org.apache.maven.plugin.assembly.AssemblyMojo.execute(AssemblyMojo.java:173)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
... 16 more
Caused by: org.codehaus.plexus.archiver.ArchiverException: webxml
attribute is required
at
org.codehaus.plexus.archiver.war.WarArchiver.initZipOutputStream(WarArchiver.java:139)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:327)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:229)
at
org.apache.maven.plugin.assembly.AssemblyMojo.createArchive(AssemblyMojo.java:215)
at
org.apache.maven.plugin.assembly.AssemblyMojo.execute(AssemblyMojo.java:165)
... 18 more
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Fri Oct 21 12:44:25 CEST 2005
[INFO] Final Memory: 3M/7M
[INFO]
was:
Trying to use the assembly plugin
[jira] Closed: (MNG-1274) maven-assembly doesn't support war format
[ http://jira.codehaus.org/browse/MNG-1274?page=all ]
John Casey closed MNG-1274:
---
Resolution: Fixed
Applied. Thanks, Jerome.
> maven-assembly doesn't support war format
> -
>
> Key: MNG-1274
> URL: http://jira.codehaus.org/browse/MNG-1274
> Project: Maven 2
> Type: Bug
> Components: maven-assembly-plugin
> Versions: 2.0
> Reporter: Jerome Lacoste
> Assignee: John Casey
> Attachments: MNG-1274.diff, MNG-1274_plexus_archiver_ignore_webxml.diff
>
> Original Estimate: 30 minutes
>Time Spent: 30 minutes
> Remaining: 0 minutes
>
> Trying to use the assembly plugin to repackage a war, I got the exception
> below. The functionality was needed to implemented multi-webstart application
> deployment in relation to the Webstart Plugin [1]
> It fails miserably because of the missing webxml attribute required by the
> WebArchiver, triggered because the specified format is war.
> I was told on #maven that the assembly is not meant to package war. I don't
> see why it couldn't :) So I mailed on @users [2]. Someone also asked for
> similar funcionality [3].
> So repackaging a war is clearly an required functionality.
> Should we consider the assembly plugin one way to implement this feature, and
> this is issue is indeed real?
> Or should I take another approach, like move the assembly plugin execution as
> part of an earlier phase (e.g. process-resources) inside the war project ?
> Some links
> Links:
> [1] http://docs.codehaus.org/display/MOJO/Webstart+Plugin
> [2] http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/29177
> [3] http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/29243
> Here's my assmbly descriptor:
>
> main
>
> war
>
> false
>
>
> /
>
> myproject:webapp
>
> true
> runtime
>
>
> webstart
>
> myproject:webstart1
>
> true
> runtime
>
>
>
> and here's a part of the pom
>
>
> myproject
> webapp
> ${version}
> war
>
>
> myproject
> webstart1
> ${version}
> zip
>
> Here's the log:
> [DEBUG] -- end configuration --
> [INFO] [assembly:assembly]
> [...]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error creating assembly: webxml attribute is required
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error creating
> assembly: webxml attribute is required
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544)
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482)
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452)
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:214)
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
>at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:585)
>at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> creating assembly: webxml attribute is required
>at
> org.apache.maven.plugin.assembly.AssemblyMojo.execute(AssemblyMojo.java:173)
>at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
>... 16 more
> Caused by: org.codehaus.plexus.archiver.ArchiverException: webxml
> attribute is required
>at
> org.codehaus.plexus.archiver.war.WarArchiver.init
Re: [M2] Building throught a proxy?
Damn I just found my answer in the readme file. I had forgotten to read it. Sorry! On 11/15/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > Hi, I know how to define my proxy settings when maven is already built, > but how can I define them before building maven from the source so all the > plugins it needs can be downloaded? > > Thank! > > -- > Alexandre Poitras > Québec, Canada -- Alexandre Poitras Québec, Canada
[M2] Building throught a proxy?
Hi, I know how to define my proxy settings when maven is already built, but how can I define them before building maven from the source so all the plugins it needs can be downloaded? Thank! -- Alexandre Poitras Québec, Canada
[jira] Commented: (MNG-1509) Profile activation by os doesn't work
[ http://jira.codehaus.org/browse/MNG-1509?page=comments#action_51028 ] Bernd Bohmann commented on MNG-1509: patch included > Profile activation by os doesn't work > - > > Key: MNG-1509 > URL: http://jira.codehaus.org/browse/MNG-1509 > Project: Maven 2 > Type: Bug > Components: maven-project > Versions: 2.0 > Environment: Ubuntu 5.10 maven 2.0 > Reporter: Bernd Bohmann > Attachments: DefaultProfileManagerTest.java.patch, > OperatingSystemProfileActivator.java.patch, components.xml.patch > > > Profile activation by os doesn't work. > OperatingSystemProfileActivator is missing in components.xml. > Implementation of OperatingSystemProfileActivator.isActive is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1469) pmd has problems with package-info.java.
[ http://jira.codehaus.org/browse/MNG-1469?page=comments#action_51027 ] Bernd Bohmann commented on MNG-1469: patch included > pmd has problems with package-info.java. > > > Key: MNG-1469 > URL: http://jira.codehaus.org/browse/MNG-1469 > Project: Maven 2 > Type: Bug > Components: maven-pmd-plugin > Versions: 2.0 > Environment: Ubuntu 5.10 > Reporter: Bernd Bohmann > Priority: Minor > Attachments: PmdReport.java.patch > > > pmd has problems with package-info.java. Please exclude package-info.java > from report. > package-info.java can be used in place of package.html (which supports only > comments, not annotations) > Please update to pmd version 3.3 > Embedded error: Failure executing PMD for: > myfaces/tobago/taglib/component/package-info.java > Encountered "package" at line 27, column 1. > Was expecting one of: > "class" ... > "final" ... > "interface" ... > ... > "@" ... > "public" ... > "static" ... > "protected" ... > "private" ... > "abstract" ... > "synchronized" ... > "native" ... > "transient" ... > "volatile" ... > "strictfp" ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1455) Possible NPE in DefaultArtifactResolver
[ http://jira.codehaus.org/browse/MNG-1455?page=comments#action_51026 ] Bernd Bohmann commented on MNG-1455: patch included > Possible NPE in DefaultArtifactResolver > --- > > Key: MNG-1455 > URL: http://jira.codehaus.org/browse/MNG-1455 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Versions: 2.0 > Environment: Ubuntu /Windows 2000 > Reporter: Bernd Bohmann > Attachments: DefaultArtifactResolver.java.patch > > > With mvn site:site we got a NPE at > org.apache.maven.aritfact.resolver.DefaultArtifactResolver.java Line 82 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPXDOC-30) Not very informative error message on xdoc template error
[ http://jira.codehaus.org/browse/MPXDOC-30?page=all ] Lukas Theussl closed MPXDOC-30: --- Resolution: Won't Fix Fix Version: 1.10 > Not very informative error message on xdoc template error > - > > Key: MPXDOC-30 > URL: http://jira.codehaus.org/browse/MPXDOC-30 > Project: maven-xdoc-plugin > Type: Improvement > Reporter: Per Olesen > Priority: Trivial > Fix For: 1.10 > > > Hi, > Had a problem where a wrong value inside the project.xml > element gave me a not very informative error > message: > File.. file:/home/polesen/.maven/plugins/maven-xdoc-plugin-1.4/ > Element... velocity:merge > Line.. 399 > Column 9 > Invocation of method 'getCvsRoot' in class > org.apache.maven.project.Repository threw exception class > java.lang.IllegalArgumentException : repository connection string contains > more than six tokens > It took me some time, and some searching around inside the xdoc plugin files, > to find out what my problem was. > I do not know if it is easy to give a better message, or if it is a result of > the use of velocity templates!? Anyways, I think a newcomer will have some > problems finding out what's wrong! > /Per -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Tue Nov 15 18:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051115.183000.txt
[jira] Closed: (MPXDOC-21) Customization template
[ http://jira.codehaus.org/browse/MPXDOC-21?page=all ]
Lukas Theussl closed MPXDOC-21:
---
Resolution: Duplicate
Superceded by MPXDOC-183
> Customization template
> --
>
> Key: MPXDOC-21
> URL: http://jira.codehaus.org/browse/MPXDOC-21
> Project: maven-xdoc-plugin
> Type: Bug
> Reporter: Claudio D'Angelo
> Priority: Minor
>
>
> XDOC Plugin use the template, to generate the project informations pages,
> under ${plugin.resources}/templates.
> In the PLUGIN.JELLY can be change :
> name="${maven.gen.docs}/${pomDocument}"
> basedir="${plugin.resources}/templates"
> template="${pomDocument}"
> inputEncoding="${encoding}"
> outputEncoding="${encoding}"
> />
> in
> name="${maven.gen.docs}/${pomDocument}"
> basedir="${template}"
> template="${pomDocument}"
> inputEncoding="${encoding}"
> outputEncoding="${encoding}"
> />
> where the property template has the default = ${plugin.resources}/templates
> but an user can change the template directory using the project.properties
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPXDOC-15) misplaced text in xdocs should be reported
[ http://jira.codehaus.org/browse/MPXDOC-15?page=all ] Lukas Theussl closed MPXDOC-15: --- Resolution: Won't Fix Fix Version: 1.10 These errors are reported by the xdoc:validate goal. > misplaced text in xdocs should be reported > -- > > Key: MPXDOC-15 > URL: http://jira.codehaus.org/browse/MPXDOC-15 > Project: maven-xdoc-plugin > Type: Improvement > Reporter: Ramon Casha > Fix For: 1.10 > > > If some text or tag in an xdoc is placed outside the correct place, it is > silently skipped. eg: if some documentation text is inadvertently placed > outside a section tag, it will simply disappear. Ideally this should be > reported as a warning/error by the plugin, but a quick workaround might be to > add a "catch-all" xsl tag which highlights the text in question at the end of > a page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPRELEASE-14) release:perform could update the date attribute in the changes.xml
release:perform could update the date attribute in the changes.xml --- Key: MPRELEASE-14 URL: http://jira.codehaus.org/browse/MPRELEASE-14 Project: maven-release-plugin Type: New Feature Reporter: Olivier Lamy Priority: Minor Could the release:perform made a simple update with the date in changes.xml as maven do. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Tue Nov 15 17:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051115.173000.txt
[jira] Updated: (MNG-1579) Exception: Can't find resource bundle for current bundle
[ http://jira.codehaus.org/browse/MNG-1579?page=all ] Lukas Theussl updated MNG-1579: --- Component: maven-checkstyle-plugin > Exception: Can't find resource bundle for current bundle > > > Key: MNG-1579 > URL: http://jira.codehaus.org/browse/MNG-1579 > Project: Maven 2 > Type: Bug > Components: maven-checkstyle-plugin > Versions: 2.0 > Environment: WinXP SP2 > Maven 2.0 > maven-checkstyle-plugin 2.0-beta-1 > Reporter: Michael Böckling > > > When I try to execute mvn site with checkstyle configured in my POM, it > throws an exception saying it can't find the resource bundle for my locale. > Explicitly setting en in my POM has not effect. > Console: > [INFO] [site:site] > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Can't find bundle for base name checkstyle-report, locale de_CH > [INFO] > - > --- > [INFO] Trace > java.util.MissingResourceException: Can't find bundle for base name > checkstyle-r > eport, locale de_CH > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle > .java:804) > at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:773) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:661) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.getBundle(Checkst > yleReport.java:539) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.getName(Checkstyl > eReport.java:201) > at > org.apache.maven.plugins.site.ReportComparator.compare(ReportComparat > or.java:40) > at java.util.Arrays.mergeSort(Arrays.java:1278) > at java.util.Arrays.sort(Arrays.java:1219) > at java.util.Collections.sort(Collections.java:155) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:399) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi > fecycle(DefaultLifecycleExecutor.java:469) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:448) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MNG-1579) Exception: Can't find resource bundle for current bundle
[ http://jira.codehaus.org/browse/MNG-1579?page=all ] Lukas Theussl moved MPCHECKSTYLE-44 to MNG-1579: Version: (was: 2.0) 2.0 Complexity: Intermediate Workflow: Maven (was: jira) Key: MNG-1579 (was: MPCHECKSTYLE-44) Project: Maven 2 (was: maven-checkstyle-plugin) > Exception: Can't find resource bundle for current bundle > > > Key: MNG-1579 > URL: http://jira.codehaus.org/browse/MNG-1579 > Project: Maven 2 > Type: Bug > Components: maven-checkstyle-plugin > Versions: 2.0 > Environment: WinXP SP2 > Maven 2.0 > maven-checkstyle-plugin 2.0-beta-1 > Reporter: Michael Böckling > > > When I try to execute mvn site with checkstyle configured in my POM, it > throws an exception saying it can't find the resource bundle for my locale. > Explicitly setting en in my POM has not effect. > Console: > [INFO] [site:site] > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Can't find bundle for base name checkstyle-report, locale de_CH > [INFO] > - > --- > [INFO] Trace > java.util.MissingResourceException: Can't find bundle for base name > checkstyle-r > eport, locale de_CH > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle > .java:804) > at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:773) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:661) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.getBundle(Checkst > yleReport.java:539) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.getName(Checkstyl > eReport.java:201) > at > org.apache.maven.plugins.site.ReportComparator.compare(ReportComparat > or.java:40) > at java.util.Arrays.mergeSort(Arrays.java:1278) > at java.util.Arrays.sort(Arrays.java:1219) > at java.util.Collections.sort(Collections.java:155) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:399) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi > fecycle(DefaultLifecycleExecutor.java:469) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:448) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MPXDOC-183) Enable User Templates in XDOC plugin
[ http://jira.codehaus.org/browse/MPXDOC-183?page=all ] Lukas Theussl moved MAVEN-1725 to MPXDOC-183: - Workflow: jira (was: Maven) Key: MPXDOC-183 (was: MAVEN-1725) Project: maven-xdoc-plugin (was: Maven) > Enable User Templates in XDOC plugin > > > Key: MPXDOC-183 > URL: http://jira.codehaus.org/browse/MPXDOC-183 > Project: maven-xdoc-plugin > Type: New Feature > Reporter: Niall Pemberton > Priority: Minor > Attachments: xdoc-user-template.patch, xdoc-user-template2.patch > > > It would be useful to allow custom user templates to be specified in the xdoc > plugin, as perr this thread: > http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg69686.html > I suggest allowing a "user template directory" to be specified and the xdoc > plugin check for the existence of a user template there. > Attaching a patch to do this (I tested these changes by hacking my cached > version 1.9.2 of the xdoc plugin, but not against the current svn version). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Tue Nov 15 17:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051115.171501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.171501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Tue Nov 15 17:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051115.17.txt
RE: svn commit: r344386 - /maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java
Thanks John,
When I deploy now the resolved version is 0.7-SNASPHOT and not the
timestamped version.
It may work but that means that builds will not be reproducible, because the
correct dependency version will be chosen at runtime according to the
available snapshots, right?
Thanks
-Vincent
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: mardi 15 novembre 2005 17:15
> To: commits@maven.apache.org
> Subject: svn commit: r344386 - /maven/components/trunk/maven-
> project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
> adata.java
>
> Author: jdcasey
> Date: Tue Nov 15 08:15:21 2005
> New Revision: 344386
>
> URL: http://svn.apache.org/viewcvs?rev=344386&view=rev
> Log:
> Decoupling ${version} expressions from POM version before resolving it to
> a buildnumber/timestamp on install or deploy.
>
> Modified:
> maven/components/trunk/maven-
> project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
> adata.java
>
> Modified: maven/components/trunk/maven-
> project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
> adata.java
> URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-
> project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
> adata.java?rev=344386&r1=344385&r2=344386&view=diff
> ==
>
> --- maven/components/trunk/maven-
> project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
> adata.java (original)
> +++ maven/components/trunk/maven-
> project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMet
> adata.java Tue Nov 15 08:15:21 2005
> @@ -34,6 +34,8 @@
> import java.io.FileReader;
> import java.io.FileWriter;
> import java.io.IOException;
> +import java.io.StringReader;
> +import java.io.StringWriter;
>
> /**
> * Attach a POM to an artifact.
> @@ -85,10 +87,17 @@
> try
> {
> reader = new FileReader( file );
> +StringWriter sWriter = new StringWriter();
> +IOUtil.copy( reader, sWriter );
> +
> +String modelSrc = sWriter.toString().replaceAll(
> "\\$\\{(pom\\.|project\\.)?version\\}", artifact.getBaseVersion() );
> +
> +StringReader sReader = new StringReader( modelSrc );
> +
> writer = new FileWriter( destination );
>
> MavenXpp3Reader modelReader = new MavenXpp3Reader();
> -Model model = modelReader.read( reader );
> +Model model = modelReader.read( sReader );
> model.setVersion( artifact.getVersion() );
>
> DistributionManagement distributionManagement =
> model.getDistributionManagement();
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Tue Nov 15 16:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051115.163000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.163000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-447) Remove Project Exception
Remove Project Exception Key: CONTINUUM-447 URL: http://jira.codehaus.org/browse/CONTINUUM-447 Project: Continuum Type: Bug Versions: 1.0.1 Environment: Windows 2000 sp4 OS, 1GB of RAM, 1.70 GHz CPU Reporter: Michael Fiedler Priority: Minor I created build projects for each subproject. Once I correctly added the higher level POM (containing all of the sub projects), I wanted to delete each of the sub projects that I had added. I started to delete them from the build machine (which is running Continuum). To do it quicker, I also started to delete them from my machine. While deleting one of them, I received the following stacktrace: ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL PROTECTED] [org.apache.maven.continuum.ContinuumException: No such object.] at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) /-- Encapsulated exception \ org.apache.maven.continuum.ContinuumException: No such object. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:1729) at org.apache.maven.continuum.DefaultContinuum.removeProject(DefaultContinuum.java:210) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.ja
RE: svn commit: r344377 - /maven/components/trunk/m2-bootstrap-all.bat
> -Original Message- > From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] > Sent: mardi 15 novembre 2005 17:31 > To: dev@maven.apache.org > Subject: Re: svn commit: r344377 - /maven/components/trunk/m2-bootstrap- > all.bat > > It will be better to find and fix the pb in maven instead of this > bootstrap script Obviously... Nobody is going to disagree with you on this... :-) BTW this is also true for the unix version. Do you have a patch? Right now this allows building on windows. This has been going on for weeks/months like this with a broken bootstrap. So, there's little change it's going to be fixed anytime soon if nobody works on it. At least now m2 can be built. Thanks -Vincent > [EMAIL PROTECTED] a écrit : > > Author: vmassol > > Date: Tue Nov 15 07:37:46 2005 > > New Revision: 344377 > > > > URL: http://svn.apache.org/viewcvs?rev=344377&view=rev > > Log: > > Fixed bootstrap on windows. For some reason the plugin plugin doesn't > build the first time so we need to build it twice... > > > > Modified: > > maven/components/trunk/m2-bootstrap-all.bat > > > > Modified: maven/components/trunk/m2-bootstrap-all.bat > > URL: http://svn.apache.org/viewcvs/maven/components/trunk/m2-bootstrap- > all.bat?rev=344377&r1=344376&r2=344377&view=diff > > > == > > > --- maven/components/trunk/m2-bootstrap-all.bat (original) > > +++ maven/components/trunk/m2-bootstrap-all.bat Tue Nov 15 07:37:46 2005 > > @@ -120,6 +120,12 @@ > > echo -- > - > > echo Rebuilding maven2 plugins > > echo -- > - > > + > > [EMAIL PROTECTED] Build plugin plugin first, it seems to choke on the > > version built > by the bootstrap > > +cd maven-plugins\maven-plugin-plugin > > +call mvn --no-plugin-registry --batch-mode --fail-at-end -e > %MAVEN_CMD_LINE_ARGS% clean:clean install > > +cd ..\.. > > + > > cd maven-plugins > > @REM update the release info to ensure these versions get used in the > integration tests > > call mvn --no-plugin-registry --batch-mode -DupdateReleaseInfo=true -e > %MAVEN_CMD_LINE_ARGS% clean:clean install > > > > > > > > > > > > > - > 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]
[jira] Updated: (MAVEN-1725) Enable User Templates in XDOC plugin
[ http://jira.codehaus.org/browse/MAVEN-1725?page=all ] Niall Pemberton updated MAVEN-1725: --- Attachment: xdoc-user-template2.patch Woops, sorry missed a bit of the change when cut & pasting - attaching new patch version > Enable User Templates in XDOC plugin > > > Key: MAVEN-1725 > URL: http://jira.codehaus.org/browse/MAVEN-1725 > Project: Maven > Type: New Feature > Reporter: Niall Pemberton > Priority: Minor > Attachments: xdoc-user-template.patch, xdoc-user-template2.patch > > > It would be useful to allow custom user templates to be specified in the xdoc > plugin, as perr this thread: > http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg69686.html > I suggest allowing a "user template directory" to be specified and the xdoc > plugin check for the existence of a user template there. > Attaching a patch to do this (I tested these changes by hacking my cached > version 1.9.2 of the xdoc plugin, but not against the current svn version). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-1725) Enable User Templates in XDOC plugin
Enable User Templates in XDOC plugin Key: MAVEN-1725 URL: http://jira.codehaus.org/browse/MAVEN-1725 Project: Maven Type: New Feature Reporter: Niall Pemberton Priority: Minor Attachments: xdoc-user-template.patch It would be useful to allow custom user templates to be specified in the xdoc plugin, as perr this thread: http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg69686.html I suggest allowing a "user template directory" to be specified and the xdoc plugin check for the existence of a user template there. Attaching a patch to do this (I tested these changes by hacking my cached version 1.9.2 of the xdoc plugin, but not against the current svn version). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPCHECKSTYLE-44) Exception: Can't find resource bundle for current bundle
Exception: Can't find resource bundle for current bundle Key: MPCHECKSTYLE-44 URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-44 Project: maven-checkstyle-plugin Type: Bug Versions: 2.0 Environment: WinXP SP2 Maven 2.0 maven-checkstyle-plugin 2.0-beta-1 Reporter: Michael Böckling When I try to execute mvn site with checkstyle configured in my POM, it throws an exception saying it can't find the resource bundle for my locale. Explicitly setting en in my POM has not effect. Console: [INFO] [site:site] [INFO] - --- [ERROR] FATAL ERROR [INFO] - --- [INFO] Can't find bundle for base name checkstyle-report, locale de_CH [INFO] - --- [INFO] Trace java.util.MissingResourceException: Can't find bundle for base name checkstyle-r eport, locale de_CH at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle .java:804) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:773) at java.util.ResourceBundle.getBundle(ResourceBundle.java:661) at org.apache.maven.plugin.checkstyle.CheckstyleReport.getBundle(Checkst yleReport.java:539) at org.apache.maven.plugin.checkstyle.CheckstyleReport.getName(Checkstyl eReport.java:201) at org.apache.maven.plugins.site.ReportComparator.compare(ReportComparat or.java:40) at java.util.Arrays.mergeSort(Arrays.java:1278) at java.util.Arrays.sort(Arrays.java:1219) at java.util.Collections.sort(Collections.java:155) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:399) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r344377 - /maven/components/trunk/m2-bootstrap-all.bat
It will be better to find and fix the pb in maven instead of this bootstrap script Emmanuel [EMAIL PROTECTED] a écrit : Author: vmassol Date: Tue Nov 15 07:37:46 2005 New Revision: 344377 URL: http://svn.apache.org/viewcvs?rev=344377&view=rev Log: Fixed bootstrap on windows. For some reason the plugin plugin doesn't build the first time so we need to build it twice... Modified: maven/components/trunk/m2-bootstrap-all.bat Modified: maven/components/trunk/m2-bootstrap-all.bat URL: http://svn.apache.org/viewcvs/maven/components/trunk/m2-bootstrap-all.bat?rev=344377&r1=344376&r2=344377&view=diff == --- maven/components/trunk/m2-bootstrap-all.bat (original) +++ maven/components/trunk/m2-bootstrap-all.bat Tue Nov 15 07:37:46 2005 @@ -120,6 +120,12 @@ echo --- echo Rebuilding maven2 plugins echo --- + [EMAIL PROTECTED] Build plugin plugin first, it seems to choke on the version built by the bootstrap +cd maven-plugins\maven-plugin-plugin +call mvn --no-plugin-registry --batch-mode --fail-at-end -e %MAVEN_CMD_LINE_ARGS% clean:clean install +cd ..\.. + cd maven-plugins @REM update the release info to ensure these versions get used in the integration tests call mvn --no-plugin-registry --batch-mode -DupdateReleaseInfo=true -e %MAVEN_CMD_LINE_ARGS% clean:clean install - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Tue Nov 15 15:45:01 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051115.154501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.154501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1574) trouble with invalid pom (failed cli site:site)
[ http://jira.codehaus.org/browse/MNG-1574?page=all ] Olivier Lamy closed MNG-1574: - Resolution: Fixed Move to MEV. > trouble with invalid pom (failed cli site:site) > --- > > Key: MNG-1574 > URL: http://jira.codehaus.org/browse/MNG-1574 > Project: Maven 2 > Type: Bug > Components: maven-project-info-reports-plugin > Versions: 2.0 > Environment: windows and solaris > Reporter: Olivier Lamy > Priority: Blocker > > > Hi, > I use a dependencie > > commons-configuration > commons-configuration > 1.1 > > I have the following exceptions and this fails the cli : site:site. Is there > any workaround by specifying a scope in the dependency .. > [WARNING] POM for: 'commons-configuration:commons-configuration:pom:1.1' does > not appear to be valid. Its will be ignored for artifact resolution. > Reason: Failed to validate POM > ... > [INFO] Generate "Dependencies" report. > [INFO] > --- > - > [ERROR] FATAL ERROR > [INFO] > --- > - > [INFO] Can't find a valid Maven project in the repository for the artifact > [commons-configuration:commons-configuration:1.1]. > [INFO] > --- > - > [INFO] Trace > java.lang.IllegalArgumentException: Can't find a valid Maven project in the > repository for the artifact [commons-configuration:commons-configuration:1.1]. > at > org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRend > erer.renderBody(DependenciesReport.java:246) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1578) mvn assembly:assembly fails if there is no target directory already present
mvn assembly:assembly fails if there is no target directory already present --- Key: MNG-1578 URL: http://jira.codehaus.org/browse/MNG-1578 Project: Maven 2 Type: Bug Reporter: Matthew Pocock Priority: Minor I have a module that is of type pom. Its job is to agregate a set of dependencies. I want to build a distribution from these, so I tried the assembly plugin. I did get it to work. However, on the way I got this error: [INFO] [assembly:assembly] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error creating assembly: /home/nmrp3/devel/derkholm/bjv2/trunk/clis/cli/target isn't a directory. A build for a pom project doesn't make a target directory. But, assembly:assembly requires one. I've made the directory manually and now the assembly builds just fine. The stack-trace is below. I've modified my assembly descriptor file to not mention target/** at all, and it now builds just fine without the target directory being present. The path of least suprise for the end-user would be to behave as if there were no files to find if target is absent and a search is done within target for files. [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error creating assembly: /home/nmrp3/devel/derkholm/bjv2/trunk/clis/cli/target isn't a directory. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:214) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating assembly: /home/nmrp3/devel/derkholm/bjv2/trunk/clis/cli/target isn't a directory. at org.apache.maven.plugin.assembly.AssemblyMojo.execute(AssemblyMojo.java:173) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) ... 16 more Caused by: org.codehaus.plexus.archiver.ArchiverException: /home/nmrp3/devel/derkholm/bjv2/trunk/clis/cli/target isn't a directory. at org.codehaus.plexus.archiver.AbstractArchiver.addDirectory(AbstractArchiver.java:125) at org.apache.maven.plugin.assembly.AssemblyMojo.addDirectory(AssemblyMojo.java:377) at org.apache.maven.plugin.assembly.AssemblyMojo.processFileSets(AssemblyMojo.java:459) at org.apache.maven.plugin.assembly.AssemblyMojo.createArchive(AssemblyMojo.java:209) at org.apache.maven.plugin.assembly.AssemblyMojo.execute(AssemblyMojo.java:165) ... 18 more [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Tue Nov 15 16:03:51 GMT 2005 [INFO] Final Memory: 3M/6M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with Integration-test and plexus compiler
I needed to do a bit of compiling after the process-classes phase for a
couple of custom plugins...so I pulled out the interesting parts of the
compiler mojo and used that...not sure if there is a better way, but this
certainly works..
jesse
private Compiler compiler = new JavacCompiler();
private void compile(String file) throws MojoExecutionException {
getLog().debug("outputDir " + outputDirectory);
getLog().debug("file " + file);
getLog().debug("build to " + buildDirectory);
try {
CompilerConfiguration compilerConfiguration = new CompilerConfiguration();
compilerConfiguration.setOutputLocation( buildDirectory + "/classes" );
ArrayList list = new ArrayList();
list.add(outputDirectory);
compilerConfiguration.setSourceLocations( list );
compilerConfiguration.setClasspathEntries(
project.getCompileClasspathElements() );
HashSet set = new HashSet();
set.add(new File(file));
compilerConfiguration.setSourceFiles( set );
compilerConfiguration.setDebug( true );
List messages = null;
messages = compiler.compile( compilerConfiguration );
}
catch ( Exception e )
{
e.printStackTrace();
// TODO: don't catch Exception
throw new MojoExecutionException( "Fatal error compiling", e );
}
}
On 11/15/05, Pablo <[EMAIL PROTECTED]> wrote:
>
> Hello there
>
> I'm writting a plugin which is supposed to do a few things:
> 1) Compile test classes to be run in integration-test phase
> 2) Start tomcat
> 3) Run tests
> 4) Stop tomcat
>
> Steps 2, 3 and 4 are almost done. The main problem is step 1.
> I thought it would be too much to do by implementing compilation from
> scratch therefore I simply created a class extending TestCompilerMojo
> class.
> Unfortunatelly it doesn't work, throws exception because CompilerManager
> is not initialized. I tried to make it by myself by setting necessary
> field in execute() method (compilerManager, compilerId) and now it
> doesn't throw any exceptions.
>
> In plugin configuration I've placed 'compileSourceRoots' and
> ''outputDirectory' but it seems that these values are not set because I
> got a message:
> '[INFO] No sources to compile'
>
> Can someone point me to some tutorial or HOWTO describing all necessary
> steps to make it work?
>
> I don't want to place integration tests in the same directory as normal
> junit tests because these tests are supposed to be run after tomcat is
> started with web application running in the *integration-test* phase not
> the *test* phase. If they were placed in src/tests the *package* phase
> would return error since there would be no webapp running *(test* is
> before *package* phase).
>
> Thanks in advance.
> Pablo
>
>
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
[jira] Commented: (MNG-1353) Allow creating POJO config classes anywhere without requiring the plugin user to specify an implementation element
[ http://jira.codehaus.org/browse/MNG-1353?page=comments#action_51007 ] Vincent Massol commented on MNG-1353: - Brett,this would be needed for any parameter. The goal is to move the config POJO out of the directory where the mojos are so that they can be placed anywhere. > Allow creating POJO config classes anywhere without requiring the plugin user > to specify an implementation element > -- > > Key: MNG-1353 > URL: http://jira.codehaus.org/browse/MNG-1353 > Project: Maven 2 > Type: Task > Components: maven-core > Versions: 2.0 > Reporter: Vincent Massol > Assignee: Jason van Zyl > Fix For: 2.1 > > > This is really important for several reasons: > * I don't like to clutter my main plugin package with POJO classes. For the > Cargo m2 plugin I have 7-8 POJO classes and I'd like to move them to a > different package > * I need to reuse existing POJOs from another jar and it's just too stupid to > have to duplicate all the code or write wrapper classes with only > getter/setters. > I think the best solution would be to accept @implementation javadoc tags > that would map a parameter to an implementation. This would need to work not > only for Mojo classes but also for POJO classes being used for configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Snapshots and version resolution
Hi, I have uploaded the cargo m2 plugin to a private repo and I'm trying to use it from a m2 project. All the cargo artifacts that I have uploaded are snapshots. They all have a different resolved timestamp. However when I run the cargo m2 plugin on my m2 project m2 looks for a an artifact (cargo-core-generic) with the resolved timestamp version of the cargo m2 plugin (20051115.115553-2 as shown on http://cargo.codehaus.org/dist2/org/codehaus/cargo/maven2/cargo-maven2-plugi n/0.7-SNAPSHOT/). Of course this version is not found for the cargo-core-generic artifact: http://cargo.codehaus.org/dist2/org/codehaus/cargo/core/cargo-core-generic/0 .7-SNAPSHOT/ Is that a bug? Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Tue Nov 15 13:45:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051115.134500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.134500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1577) dependencyManagent does not work for transient dependencies
dependencyManagent does not work for transient dependencies --- Key: MNG-1577 URL: http://jira.codehaus.org/browse/MNG-1577 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: Joerg Schaible The dependencyManagement does not work for transient dependencies. The specified version is ignored. Use case: Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT Project A is child of Main and depends directly on commons-beanutils (version inherited from Main) Project B is child of Main and depends directly on commons-digester (version inherited from Main) Project C is child of Main and depends directly on A & B (versions inherited from Main) A is compiled and tests are run using commons-beanutils-1.7.0 B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this C is compiled and tests are run using commons-beanutils-1.7.0 Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized. If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority. - Jörg -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1576) PMD does not work on dutch locale
PMD does not work on dutch locale - Key: MNG-1576 URL: http://jira.codehaus.org/browse/MNG-1576 Project: Maven 2 Type: Bug Components: maven-pmd-plugin Reporter: Wim Deblauwe I get the following error when running mvn site with pmd report enabled: [ERROR] FATAL ERROR [INFO] [INFO] Can't find bundle for base name pmd-report, locale nl_NL [INFO] [INFO] Trace java.util.MissingResourceException: Can't find bundle for base name pmd-report, locale nl_NL at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:806) at java.util.ResourceBundle.getBundle(ResourceBundle.java:700) at org.apache.maven.plugin.pmd.PmdReport.getBundle(PmdReport.java:232) at org.apache.maven.plugin.pmd.PmdReport.getName(PmdReport.java:82) at org.apache.maven.plugins.site.ReportComparator.compare(ReportComparator.java:40) at java.util.Arrays.mergeSort(Arrays.java:1284) at java.util.Arrays.sort(Arrays.java:1223) at java.util.Collections.sort(Collections.java:159) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Tue Nov 15 14:42:35 CET 2005 [INFO] Final Memory: 9M/16M [INFO] regards, Wim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - checkout] Tue Nov 15 13:27:37 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.132737.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JIRA projects for m2 plugins?
I am ready to check in the Weblogic Plugin. I think it makes sense to create new projects for these plugins since the structure will be quite different. This also allows us to keep maintaining the version 1.0 plugins as well. I woiuld prefer that we start with 2.0 for a number of reasons since I want to keep maintaining the 1.0 plugin for a while as well. I plan on having an alpha and beta version since I am discovering some new ideas with the advent of the native Java option as well as new interaction with the container. Do we want one main maven2 project with sub projects under that or should we create a maven2 directory under each project? I too would like to get my code into the repository ASAP. Looking forward to everyone's input. Scott D. Ryan Chief Technology Officer Soaring Eagle LLC. 9742 S. Whitecliff Place Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 15, 2005 1:58 AM To: 'Maven Developers List' Subject: JIRA projects for m2 plugins? So what's the status on this? - Have we decided to create separate JIRA projects for m2 plugins? - Can I create a Clover JIRA project the m2 clover plugin? I'd like to get moving on this. - Is there any recommendation for versioning the plugins? Should we start at 2.0 and simply increase the minor? Do plugins have to go through alphas, betas, rcs or is it left at the discretion of the plugin contributors in general? Thanks -Vincent - 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]
[jira] Updated: (MEV-197) Improvements for Commons Chain pom
[ http://jira.codehaus.org/browse/MEV-197?page=all ] Wendy Smoak updated MEV-197: Attachment: chain-1.0-20051115.diff Apparently you can't reuse filenames, trying again. :) > Improvements for Commons Chain pom > -- > > Key: MEV-197 > URL: http://jira.codehaus.org/browse/MEV-197 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: Wendy Smoak > Attachments: chain-1.0-20051115.diff, chain-1.0.diff, chain-1.0.diff > > > Making some dependencies optional, changing to standard groupId for Sun jars -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-197) Improvements for Commons Chain pom
[ http://jira.codehaus.org/browse/MEV-197?page=all ] Wendy Smoak updated MEV-197: Attachment: chain-1.0.diff Replacement diff -- this one also marks JUnit as test scope. > Improvements for Commons Chain pom > -- > > Key: MEV-197 > URL: http://jira.codehaus.org/browse/MEV-197 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: Wendy Smoak > Attachments: chain-1.0.diff, chain-1.0.diff > > > Making some dependencies optional, changing to standard groupId for Sun jars -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-197) Improvements for Commons Chain pom
[ http://jira.codehaus.org/browse/MEV-197?page=comments#action_50987 ] Wendy Smoak commented on MEV-197: - Quotes from the Commons Chain docs [0]: "The "context" abstraction is designed to isolate command implementations from the environment in which they are run (such as a command that can be used in either a Servlet or Portlet, without being tied directly to the API contracts of either of these environments)." "... Convenience base class implementations of these APIs are provided, as well as more specialized (but optional) implementations for the web environment (i.e. servlets and portlets)." So Servlet really is optional in this case, not provided. (And MyFaces would only work in a Servlet environment, so it's optional as well.) I did miss 'test' scope for JUnit, though, so I'll attach another patch. Thanks! [0] http://jakarta.apache.org/commons/chain/ > Improvements for Commons Chain pom > -- > > Key: MEV-197 > URL: http://jira.codehaus.org/browse/MEV-197 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: Wendy Smoak > Attachments: chain-1.0.diff > > > Making some dependencies optional, changing to standard groupId for Sun jars -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Tue Nov 15 13:15:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051115.131500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-1724) Provide a way for a maven1 build to upload to an m2 repository
Provide a way for a maven1 build to upload to an m2 repository -- Key: MAVEN-1724 URL: http://jira.codehaus.org/browse/MAVEN-1724 Project: Maven Type: New Feature Versions: 1.1-beta-1 Reporter: Steve Loughran I have to use other people's maven1 builds (e.g. axis) but use an m2 repository internally. there appears to be no automated way of doing an equivalent of jar:install to an m2 repository, without which it is really hard to integrate the two versions of maven. I know I can set up my repository list to include a legacy repository, but that doesnt help me share releases via a team repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
