[ANN] Maven Site Plugin 1.7.1 for Maven 1.x released

[Lukas Theussl]

We are pleased to announce the Maven Site Plugin 1.7.1 release! 

http://maven.apache.org/maven-1.x/plugins/site/

Generate web site. 

===

Changes in this version include:

  Fixed bugs:

o Update files modes on the remote host after deployment with rsync (you 
  don't have to use the same rights in your local directory). 
o Update root directory mode on the remote host (rsync and ssh). 

  Changes:

o Update dependencies to unify them between plugins. The following 
  dependencies are updated : commons-net v1.4.0 to v1.4.1  

===


To automatically install the plugin, type the following on a single line:

maven plugin:download
  
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-site-plugin
  -Dversion=1.7.1

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-site-plugin-1.7.1.jar
 

Have fun!
-The Maven Site Plugin development team

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

[ANN] Maven Source Control Management Plugin 1.6.1 for Maven 1.x released

[Lukas Theussl]

We are pleased to announce the Maven Source Control Management Plugin 1.6.1 
release! 

http://maven.apache.org/maven-1.x/plugins/scm/

A plugin for SCM tasks. 

===

Changes in this version include:

  Fixed bugs:

o The prepare-release goal should fail if project.xml can't be edited (e.g. 
  read only). Fixes MPSCM-63. 
o SCM Parse Connection output is wrong / misleading. Fixes MPSCM-89. 
o scm:prepare-release does not commit modified changes.xml. Fixes MPSCM-86. 

  Changes:

o Upgrade plexus-utils to version 1.0.5 Fixes MAVEN-1803. 
o Upgrade plexus-container-default and plexus-component-api to version 
  1.0-alpha-15 and replace classworlds by plexus-classworlds 1.2-alpha-5 
o Update dom4j and jelly dependencies to match the ones in maven 1.1 core. 
o Update dependencies to unify them between plugins. The following 
  dependencies are updated : commons-jelly-tags-interaction v1.0 to v1.1, 
  jaxen v1.0-FCS-full to 1.1-beta-9. Add the dependency to jline for 
  commons-jelly-tags-interaction v1.1. 
o Upgrade to commons-io 1.2.  

===


To automatically install the plugin, type the following on a single line:

maven plugin:download
  
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-scm-plugin
  -Dversion=1.6.1

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-scm-plugin-1.6.1.jar
 

Have fun!
-The Maven Source Control Management Plugin development team

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

[ANN] Maven PMD Plugin 1.10 for Maven 1.x released

[Lukas Theussl]

We are pleased to announce the Maven PMD Plugin 1.10 release! 

http://maven.apache.org/maven-1.x/plugins/pmd/

The Maven PMD plugin is a plugin that wraps the PMD framework 
(http://pmd.sourceforge.net). PMD is a source checking framework that works by 
scanning Java source code and looks for potential problems like: unused local 
variables, empty catch blocks, unused parameters, empty 'if' statements, etc. 

===

Changes in this version include:

  New Features:

o Add "Goals" page. 
o Add an alternative jsl stylesheet that includes priority information. 
  Thanks to James Dempsey. 
o Allow custom JSL stylesheet to be defined via a property. Fixes MPPMD-27. 

  Fixed bugs:

o Cannot run pmd with Strings rulesets. Fixes MPPMD-30. 

  Changes:

o Upgrade to PMD 3.9. Fixes MPPMD-29. 
o Update/clarify properties and add "Default" column to "Properties" page. 
o Update dependencies to unify them between plugins. The following 
  dependencies are updated: jaxen v1.0-FCS-full to 1.1-beta-9. The following 
  dependencies are removed: saxpath.  

===


To automatically install the plugin, type the following on a single line:

maven plugin:download
  
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-pmd-plugin
  -Dversion=1.10

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-pmd-plugin-1.10.jar
 

Have fun!
-The Maven PMD Plugin development team

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

[ANN] Maven PDF Plugin 2.5.1 for Maven 1.x released

[Lukas Theussl]

We are pleased to announce the Maven PDF Plugin 2.5.1 release! 

http://maven.apache.org/maven-1.x/plugins/pdf/

PDF Documentation generator 

===

Changes in this version include:

  Fixed bugs:

o Unable to remove cover type and version. Fixes MPPDF-57.  

===


To automatically install the plugin, type the following on a single line:

maven plugin:download
  
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-pdf-plugin
  -Dversion=2.5.1

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-pdf-plugin-2.5.1.jar
 

Have fun!
-The Maven PDF Plugin development team

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

[ANN] Maven JDiff Plugin 1.5.1 for Maven 1.x released

[Lukas Theussl]

We are pleased to announce the Maven JDiff Plugin 1.5.1 release! 

http://maven.apache.org/maven-1.x/plugins/jdiff/

Plugin for JDiff - reports on the differences in the public API of two 
releases by comparing the sources of two SCM checkouts. 

===

Changes in this version include:

  Fixed bugs:

o Jdiff fails with svn modules. New property maven.jdiff.svn.module. Fixes 
  MPJDIFF-9. 
o Jdiff doclet fails with jdk 1.4. Fixes MPJDIFF-10. 
o Use relative links to the javadoc. 

  Changes:

o It requires at least maven-plugin-plugin v1.7.  

===


To automatically install the plugin, type the following on a single line:

maven plugin:download
  
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-jdiff-plugin
  -Dversion=1.5.1

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-jdiff-plugin-1.5.1.jar
 

Have fun!
-The Maven JDiff Plugin development team

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

[ANN] Maven Clover Plugin 1.11.2 for Maven 1.x released

[Lukas Theussl]

We are pleased to announce the Maven Clover Plugin 1.11.2 release! 

http://maven.apache.org/maven-1.x/plugins/clover/

The Clover plugin allows measuring test coverage using Clover 
(http://www.cenqua.com/clover). 

===

Changes in this version include:

  Changes:

o Use new clover license. Fixes MPCLOVER-58.  

===


To automatically install the plugin, type the following on a single line:

maven plugin:download
  
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
  -DgroupId=maven
  -DartifactId=maven-clover-plugin
  -Dversion=1.11.2

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-clover-plugin-1.11.2.jar
 

Have fun!
-The Maven Clover Plugin development team

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

what groupId for quartz ?

[nicolas de loof]

opensymphony Quartz scheduler exists on repo1.maven.org in both :

http://repo1.maven.org/maven2/quartz/quartz/
 and
http://repo1.maven.org/maven2/opensymphony/quartz/

"opensymphony" groupId contains the latest 1.6.0, so it looks to be the
expected groupId, but this one has no POM ( migrate from maven1 ? )

Could someone clarify this, perhaps add some POM to opensymphony/quarts,
maybe with relocation to "quartz" ?

Nico.

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Brett Porter]

On 29/03/2007, at 4:13 PM, Stephane Nicoll wrote:


IMO, we really need the assembly release. It's been way too long and
it's beta. Can't we fix those things for beta-2?


If John's fixed the bug I filed, then I'm happy (was just waiting for  
the new build to be announced so I could test it...)


- Brett

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

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Stephane Nicoll]

On 3/29/07, Brett Porter <[EMAIL PROTECTED]> wrote:

Agreed, in addition to making it easy to lock down your lifecycle
plugin versions. I wonder if I ever sent that proposal out for 2.1...

We just need to manage this as best we can (keep compat on x.y
versions, and separate unstable repo as I posted elsewhere).


Does not work (if you're talking about non snapshot release for unstable)

I tried to release two versions of a plugin to a corporate repo (as a
workaround). So I had maven-war-plugin-2.0.3-preview-1 in my corporate
repo and other standard versions on central.

This lead maven to alway try to get the pom from central which is
obviously not found so it creates a fake one using a template -> boum.

I've discussed this extensively with Kenney and I remember there's
something in Jira but I can't find it back.

IMO, we really need the assembly release. It's been way too long and
it's beta. Can't we fix those things for beta-2?

Stéphane


- Brett

On 29/03/2007, at 11:53 AM, Jason Dillon wrote:

> This is a general problem with the magical RELEASE version that
> plugins use... IMO this is an anti-feature and should be removed in
> general and force people to configure the plugin's version to help
> ensure that future releases of plugins don't break their builds.
>
> --jason
>
>
> On Mar 28, 2007, at 6:49 PM, John Casey wrote:
>
>> The real problem here is that as long as there are tags out there
>> that don't
>> specify plugin versions, we have no mechanism for deprecating or
>> breaking
>> api compat, regardless of the version (2.0 -> 2.1 -> 2.2 -> 99.0).
>>
>> -j
>>
>> On 3/28/07, John Casey <[EMAIL PROTECTED]> wrote:
>>>
>>> MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it
>>> to the
>>> tag...then we could roll another candidate, though I do want to
>>> resolve
>>> Max's issue above as well.
>>>
>>> Max: I'm tempted to say that we should look for decimal versions
>>> of common
>>> octal expressions, then prefix the rest with '0' to ensure they're
>>> interpreted as octal (unless they have 0x in front, that is).
>>>
>>> Is that a decent solution?
>>>
>>> -john
>>>
>>> On 3/28/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>>> >
>>> > -1
>>> >
>>> > But it got really close :)
>>> >
>>> > Unfortunately, I found a regression, though it looks a simple
>>> one to
>>> > fix: http://jira.codehaus.org/browse/MASSEMBLY-192
>>> >
>>> > I'm continuing my testing past this to see if there are any other
>>> > issues, though it looks fine.
>>> >
>>> > - Brett
>>> >
>>> > On 29/03/2007, at 2:59 AM, John Casey wrote:
>>> >
>>> > > Hi everyone,
>>> > >
>>> > > I wanted to call a vote to release a beta version of the new
>>> assembly
>>> > > plugin. There are still some outstanding issues (though not
>>> as many
>>> > > as jira
>>> > > would have you believe; they just need tests), but I think
>>> we're at
>>> > > around
>>> > > 95-99% backward compatibility and the new features seem to be
>>> > > working well.
>>> > > It's been just sitting in SVN for quite awhile now, and many
>>> people
>>> > > are
>>> > > using it directly from there. I'd like to provide better support
>>> > > for those
>>> > > people, and start getting more feedback on exactly what's still
>>> > > broken.
>>> > >
>>> > > The change list is pretty large, but is mainly concerned with
>>> > > refactoring
>>> > > the plugin away from the old monolithic approach to one that
>>> uses
>>> > > phases to
>>> > > handle the different descriptor sections, along with common task
>>> > > classes to
>>> > > handle behavior shared between phases.
>>> > >
>>> > > Road Map:
>>> > >
>>> > > http://jira.codehaus.org/secure/ReleaseNote.jspa?
>>> > > projectId=11126&styleName=Html&version=12617
>>> > >
>>> > >
>>> > > Tag:
>>> > >
>>> > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-
>>> assembly-
>>> > > plugin-2.2-beta-1
>>> > >
>>> > > Staging repository:
>>> > >
>>> > > http://people.apache.org/~jdcasey/stage/repo>> people.apache.org/%7Ejdcasey/stage/repo>
>>> > >
>>> > > Also, since this is just a beta, and there are some folks out
>>> there
>>> > > waiting
>>> > > on this release to release some of their own components, I'd
>>> like
>>> > > to make
>>> > > this a shorter vote; say, of around 24-36 hrs max. Regardless of
>>> > > whether we
>>> > > agree to do this in short order, I would like to get this
>>> release
>>> > > out on
>>> > > this vote, so don't let the timing affect your +1...if people
>>> > > complain, I'll
>>> > > just let it sit for the standard 72h.
>>> > >
>>> > > So, let's try for 24hrs. Please vote +1/+0/-1.
>>> > >
>>> > > Here's my +1.
>>> > >
>>> > > -john
>>> >
>>> >
>>> 
>>> -
>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> > For additional commands, e-mail: [EMAIL PROTECTED]
>>> >
>>> >
>>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-m

RE: maintain own metadata

[Safris]

Right! Sorry for the delay. It turns out I didnt have an account here
associated with my email address and thus I never got your response - no
matter.

1. Simply put, JAX-B is very limited in how much of the XML Schema it
actually understands (or is willing to bind). JAX-B also uses its own
annotations within the XML Schema document to help in binding. My solution,
however, solves those things JAX-B chose to leave behind. My solution is a
complete, working generator of classes from XSD documents for almost any
plausible XSD type declaration. The XSD documents do not require any
modifications to have classes be generated for them. I still need to
establish a feature list for this project, but here it is simpler to state
what is _not supported_:
a. ,
b.  simpleTypes or attributes inheriting from non-list simpleTypes
c.  containing s that are excluded from a parent
type.

2. True, the documentation is limited. Please visit http://www.safris.com
and follow the XML Toolkit link for a more in-depth explanation (still needs
a lot more content, but I hope this will do).

Again, I am very interested in the opportunity to maintain my own metadata
on the public repos. The XML Bind project has also been folded into a larger
XML Toolkit framework that is currently under busy development. Please see
http://www.safris.com for more information.


hermod.opstvedt wrote:
> 
> Hi
> 
> 1. How is this different from JaxB?
> 2. The documentation at http://xml.safris.org/bind/ leaves something to be
> desired
> 
> Hermod
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> seva safris
> Sent: Tuesday, January 23, 2007 11:08 AM
> To: dev@maven.apache.org
> Subject: maintain own metadata
> 
> 
> Hi, I have a project that I would like to be available on Maven's
> central repository. I have already had a preliminary version of my
> project deployed to repo1.maven.org, but it seems inefficient to keep
> asking you guys to have new versions deployed as time goes on. The
> project can be identified by the org.safris.xml groupId.
> 
> I would like to request that I take responsibility for maintaining my
> own metadata and set up an automated rsync system for deployment.
> Please tell me what needs to be done to make this work.
> 
> Brief description of my project:
> 
> "The XML Bind solution is an alternative approach at XML binding for
> Java. The Generator solution is capable of generating source code from
> an XSD, allowing the Runtime to marshal and unmarshal those objects
> into XML. The builders are responsible for defining task and plugin
> classes for with Ant and Maven. Builder-ant is for Ant, and
> Builder-maven is for Maven."
> 
> Project page:
> 
> http://xml.safris.org/bind/
> 
> Thank you,
> 
> seva safris
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> *
> 
> This email with attachments is solely for the use of the individual or
> entity to whom it is addressed. Please also be aware that the DnB NOR
> Group
> cannot accept any payment orders or other legally binding correspondence
> with
> customers as a part of an email. 
> 
> This email message has been virus checked by the anti virus programs used
> in the DnB NOR Group.
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> *
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/maintain-own-metadata-tf3063273s177.html#a9727257
Sent from the Maven Developers mailing list archive at Nabble.com.


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

RE: [discuss] Splitting the stable and unstable repositories

[Brian E. Fox]

>Good point, but shouldn't that stable functionality be in the  
>previous release, which folks should still be using in production  
>until they need to upgrade?

In this case, yes because the stable goals have not changed at all (and
this is where pluginMgt comes in). However if the repos are split, the
fact that the plugin as a whole is alpha means it's not easily
accessible to someone without adding a pluginRepo to their pom/settings.
Meaning that someone can't just type dependency:analyze until it's
finally released as 2.0.

> You can actually do this (yet another not well documented thing):
>mvn
org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:analyze

Good to know..this is grotesque, but still easier than changing my
"super" pom, redeploying and updating tlp poms etc just to try something
out ;-)

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

Re: [discuss] Splitting the stable and unstable repositories

[Brett Porter]

On 29/03/2007, at 1:03 PM, Brian E. Fox wrote:


Brett,
I can see some logic to this as it's just another shade of grey  
between

the current snapshot repo and central. It does however feel a little
like a hack to work around some version ranging issues. I think
massembly is a good example of where this is needed, but perhaps  
mdep is

a case where it's not. This is still in "alpha" because there are more
goals planned to be added. While the plugin overall is alpha, some of
the original goals (copy/unpack, etc) are quite mature and very  
stable.
If we did this, it would raise the bar a little higher for people  
to get

useful functionality.


Good point, but shouldn't that stable functionality be in the  
previous release, which folks should still be using in production  
until they need to upgrade?






The only thing that is slightly annoying is when you have plugins with
goals that are both meant to be bound and some for the CLI. When  
you put
a plugin in to pluginManagement, this applies even to the CLI  
versions.
I'm not sure if/how we could make this better but here's the use  
case: I

use mdep to unpack and copy stuff so I set 2.0-alpha-3 (example). But
now I want to prepare for 2.0.6 and want to run dependency:analyze  
and I
want 2.0-alpha-4, I have to change my pluginManagement. I guess a  
way to

override PMgt from the CLI would be sufficient here.



You can actually do this (yet another not well documented thing):

mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:analyze

It's pretty grotesque - and I think better ways to manage pure CLI  
plugins vs lifecycle ones in terms of versioning are definitely  
needed. We had a stab with plugin-registry, but it wasn't all that  
successful. It's actually a whole category of use cases to revise -  
like how to easily select your repositories from the CLI when you  
don't have a POM, etc. Thanks for bringing it up!


Cheers,
Brett

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

RE: [discuss] Splitting the stable and unstable repositories

[Brian E. Fox]

Brett,
I can see some logic to this as it's just another shade of grey between
the current snapshot repo and central. It does however feel a little
like a hack to work around some version ranging issues. I think
massembly is a good example of where this is needed, but perhaps mdep is
a case where it's not. This is still in "alpha" because there are more
goals planned to be added. While the plugin overall is alpha, some of
the original goals (copy/unpack, etc) are quite mature and very stable.
If we did this, it would raise the bar a little higher for people to get
useful functionality. 

I think as mentioned in the assembly thread, that perhaps RELEASE isn't
what we need. Maybe we break that down into STABLE / UNSTABLE and if
there is no existing stable version, it would grab the latest unstable
one (essentially solving both massembly by getting 2.1 and mdep by
getting the newest until it is stable)

As for plugins that are bound in poms, I think the best practice should
be to use pluginManagement. It's the only way to guarantee
reproducibility and consistency across an organization. Every plugin I
use in my corp build is controlled this way and I really have no issues
with it. 

(Slightly off topic, but related to my previous statement)

The only thing that is slightly annoying is when you have plugins with
goals that are both meant to be bound and some for the CLI. When you put
a plugin in to pluginManagement, this applies even to the CLI versions.
I'm not sure if/how we could make this better but here's the use case: I
use mdep to unpack and copy stuff so I set 2.0-alpha-3 (example). But
now I want to prepare for 2.0.6 and want to run dependency:analyze and I
want 2.0-alpha-4, I have to change my pluginManagement. I guess a way to
override PMgt from the CLI would be sufficient here.

--Brian

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 28, 2007 7:46 PM
To: Maven Developers List
Subject: [discuss] Splitting the stable and unstable repositories

Hi,

I didn't want to pin the assembly plugin vote to this, but it seemed  
like a good opportunity to bring this up.

I'd like to propose we split the stable repository from the unstable  
repository (which would be where alphas, betas and rcs get deployed),  
and make this a documented best practice.

This would not be a concept change in Maven (at least, yet - it could  
be something to consider in the versioning in future): it's simply  
two types of release repositories. The stable one would be included  
in Maven by default, the unstable/pre-release one would not. You'd  
have to add the repository to your project.

I would suggest this for future additions to central, but leave  
anything currently there in place for backwards compat.

I think this is a good all round concept, but there is a particular  
practical problem that we should do this for: unpinned plugin  
versions. In the specific example of the assembly plugin - if you  
don't request a version (ie, use latest release), or you said [2.1,),  
then you'll get the 2.2-beta-1 release which is presumably less  
stable than 2.1. The same rationalisation would apply to ranges used  
in any dependency, but thats the biggest use case I can think of that  
affects people today. It would allow us to do more regular test  
releases of the plugins.

Thoughts?

- Brett

-
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] Subscription: Outstanding Repository Maintenance: Uploads

[jira]

Issue Subscription
Filter: Outstanding Repository Maintenance: Uploads (25 issues)
Subscriber: mavendevlist


Key Summary
MAVENUPLOAD-1449Unitils provides utilities to further simplify unit-testing 
with JUnit, DBUnit, EasyMock, Hibernate and Spring. 
http://jira.codehaus.org/browse/MAVENUPLOAD-1449
MAVENUPLOAD-1448Upload Click 1.2 bundles
http://jira.codehaus.org/browse/MAVENUPLOAD-1448
MAVENUPLOAD-1447upload vraptor 2.3.2
http://jira.codehaus.org/browse/MAVENUPLOAD-1447
MAVENUPLOAD-1443Dozer Maven Upload Request
http://jira.codehaus.org/browse/MAVENUPLOAD-1443
MAVENUPLOAD-1433Include guice in the central repository
http://jira.codehaus.org/browse/MAVENUPLOAD-1433
MAVENUPLOAD-1405Eclipse SWT version 3.2.1 linux 
http://jira.codehaus.org/browse/MAVENUPLOAD-1405
MAVENUPLOAD-1399Upload xjavadoc 1.5 version to support JDK 1.5 annotations in 
xdoclet-maven-plugin
http://jira.codehaus.org/browse/MAVENUPLOAD-1399
MAVENUPLOAD-1393xulfaces 0.9 Release for maven 2
http://jira.codehaus.org/browse/MAVENUPLOAD-1393
MAVENUPLOAD-1362Upload tapestry-flash to central repo
http://jira.codehaus.org/browse/MAVENUPLOAD-1362
MAVENUPLOAD-1361Upload tapestry-prop 1.0.0 to Central repo
http://jira.codehaus.org/browse/MAVENUPLOAD-1361
MAVENUPLOAD-1355Upload Core JSF Validator (commons validator integration)
http://jira.codehaus.org/browse/MAVENUPLOAD-1355
MAVENUPLOAD-1346New IzPack jar's
http://jira.codehaus.org/browse/MAVENUPLOAD-1346
MAVENUPLOAD-1307XML Bind Builder [Ant]
http://jira.codehaus.org/browse/MAVENUPLOAD-1307
MAVENUPLOAD-1306XML Bind Generator
http://jira.codehaus.org/browse/MAVENUPLOAD-1306
MAVENUPLOAD-1308XML Bind Builder [Maven]
http://jira.codehaus.org/browse/MAVENUPLOAD-1308
MAVENUPLOAD-1305XML Bind Runtime
http://jira.codehaus.org/browse/MAVENUPLOAD-1305
MAVENUPLOAD-1284upload new artifact to The Central Repository
http://jira.codehaus.org/browse/MAVENUPLOAD-1284
MAVENUPLOAD-1267Upload of novell jldap
http://jira.codehaus.org/browse/MAVENUPLOAD-1267
MAVENUPLOAD-1149Upload jboss-seam-ui-1.0.1.jar
http://jira.codehaus.org/browse/MAVENUPLOAD-1149
MAVENUPLOAD-1148Upload jboss-seam-debug-1.0.1.jar
http://jira.codehaus.org/browse/MAVENUPLOAD-1148
MAVENUPLOAD-1147Upload jboss-seam-1.0.1.jar
http://jira.codehaus.org/browse/MAVENUPLOAD-1147
MAVENUPLOAD-1130Rhino js-1.5R4.1
http://jira.codehaus.org/browse/MAVENUPLOAD-1130
MAVENUPLOAD-1128Rhino js-1.5R3
http://jira.codehaus.org/browse/MAVENUPLOAD-1128
MAVENUPLOAD-1129Rhino js-1.5R4-RC3
http://jira.codehaus.org/browse/MAVENUPLOAD-1129
MAVENUPLOAD-976Please upload SUN Java 1.2 rutime 
http://jira.codehaus.org/browse/MAVENUPLOAD-976


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

[jira] Subscription: Outstanding Repository Maintenance: Evangelism

[jira]

Issue Subscription
Filter: Outstanding Repository Maintenance: Evangelism (39 issues)
Subscriber: mavendevlist


Key Summary
MEV-511 org.apache.struts:struts2-tiles-plugin:2.0.6 contains a SNAPSHOT 
deps
http://jira.codehaus.org/browse/MEV-511
MEV-504 Jetty 5.1.10 and 5.1.11 missing poms
http://jira.codehaus.org/browse/MEV-504
MEV-173 xmlpull JARs exist in two different places on ibiblio
http://jira.codehaus.org/browse/MEV-173
MEV-499 Latest version of clover plugin in maven.metadata.xml
http://jira.codehaus.org/browse/MEV-499
MEV-498 javax.xml.ws:jaxws-api:2.1 is bad
http://jira.codehaus.org/browse/MEV-498
MEV-36  Exo POM(s) missing dependency versions
http://jira.codehaus.org/browse/MEV-36
MEV-483 Still invalid deps in 3.2.1, 3.2.2, 3.2.3, 3.2.4
http://jira.codehaus.org/browse/MEV-483
MEV-479 Invalid POI POM
http://jira.codehaus.org/browse/MEV-479
MEV-478 jakarta-poi requires commons-lang as dependency
http://jira.codehaus.org/browse/MEV-478
MEV-457 Geronimo jar fails to download
http://jira.codehaus.org/browse/MEV-457
MEV-352 Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib
http://jira.codehaus.org/browse/MEV-352
MEV-427 relocate ehcache:ehcache to net.sf.ehcache
http://jira.codehaus.org/browse/MEV-427
MEV-471 javax.xml:jsr173:1.0 should be relocated to 
javax.xml.bind:jsr173_api:1.0
http://jira.codehaus.org/browse/MEV-471
MEV-469 jaxb-api available with two different groupIds
http://jira.codehaus.org/browse/MEV-469
MEV-375 Relocate xpp to xpp3
http://jira.codehaus.org/browse/MEV-375
MEV-443 Several projects have maven-metadata.xml files that are missing 
released versions
http://jira.codehaus.org/browse/MEV-443
MEV-461 Missing pom for commons-logging-api-1.1
http://jira.codehaus.org/browse/MEV-461
MEV-454 testng-spring has a invalid dependency on testng.
http://jira.codehaus.org/browse/MEV-454
MEV-449 lucene 1.9.1 JAR is hosed.
http://jira.codehaus.org/browse/MEV-449
MEV-448 xmlrpc POM should include commons-codec
http://jira.codehaus.org/browse/MEV-448
MEV-441 Several projects have bad maven-metadata.xml files that are 
screwing up dependencies with version range feature
http://jira.codehaus.org/browse/MEV-441
MEV-20  clean up bad IDs in the repository
http://jira.codehaus.org/browse/MEV-20
MEV-436 JOTM 2.0.10 incorrectly specifies javax.resource/connector-1.0 it 
needs connector-1.5.
http://jira.codehaus.org/browse/MEV-436
MEV-296 Activemq-core (and other activemq projects) 3.2.1 have unexpanded 
variables
http://jira.codehaus.org/browse/MEV-296
MEV-405 pom for cactus:cactus:13-1.7.2
http://jira.codehaus.org/browse/MEV-405
MEV-404 pom for cactus:cactus-ant:13-1.7.2
http://jira.codehaus.org/browse/MEV-404
MEV-401 Incoherences / duplication between javax.xml and com.sun.xml
http://jira.codehaus.org/browse/MEV-401
MEV-334 Stax POM points to an invalid XMLBeans dependency
http://jira.codehaus.org/browse/MEV-334
MEV-364 Fix dependencies of common-lang 1.0 (add test scope for junit)
http://jira.codehaus.org/browse/MEV-364
MEV-356 Missing dep on jboss-common in jbossmq-client & jnp-client 4.0.2
http://jira.codehaus.org/browse/MEV-356
MEV-351 xmlc-xerces-2.2.7.1.jar is unnecessary and  xmlc-apis.jar is 
required.
http://jira.codehaus.org/browse/MEV-351
MEV-330 WebWork 2.2.1 POM should list FreeMarker as a dependency since it's 
required for plain ol' JSPs
http://jira.codehaus.org/browse/MEV-330
MEV-325 Description of jaxb-api 1.0.1 is wrong
http://jira.codehaus.org/browse/MEV-325
MEV-320 Hibernate 3.1.x POMs pull in Sun jars
http://jira.codehaus.org/browse/MEV-320
MEV-201 should have dependency on org.relaxngdatatype.relaxngDatatype
http://jira.codehaus.org/browse/MEV-201
MEV-48  openejb poms
http://jira.codehaus.org/browse/MEV-48
MEV-45  Full list of poms that doesn't respect the m2 format
http://jira.codehaus.org/browse/MEV-45
MEV-33  XOM POM references xercesImpl v.2.2.1 which does not exist in repo
http://jira.codehaus.org/browse/MEV-33
MEV-31  XOM POM references xmlParserAPIs v2.6.1 which is not in the repo
http://jira.codehaus.org/browse/MEV-31


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

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Brett Porter]

Agreed, in addition to making it easy to lock down your lifecycle  
plugin versions. I wonder if I ever sent that proposal out for 2.1...


We just need to manage this as best we can (keep compat on x.y  
versions, and separate unstable repo as I posted elsewhere).


- Brett

On 29/03/2007, at 11:53 AM, Jason Dillon wrote:

This is a general problem with the magical RELEASE version that  
plugins use... IMO this is an anti-feature and should be removed in  
general and force people to configure the plugin's version to help  
ensure that future releases of plugins don't break their builds.


--jason


On Mar 28, 2007, at 6:49 PM, John Casey wrote:

The real problem here is that as long as there are tags out there  
that don't
specify plugin versions, we have no mechanism for deprecating or  
breaking

api compat, regardless of the version (2.0 -> 2.1 -> 2.2 -> 99.0).

-j

On 3/28/07, John Casey <[EMAIL PROTECTED]> wrote:


MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it  
to the
tag...then we could roll another candidate, though I do want to  
resolve

Max's issue above as well.

Max: I'm tempted to say that we should look for decimal versions  
of common

octal expressions, then prefix the rest with '0' to ensure they're
interpreted as octal (unless they have 0x in front, that is).

Is that a decent solution?

-john

On 3/28/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> -1
>
> But it got really close :)
>
> Unfortunately, I found a regression, though it looks a simple  
one to

> fix: http://jira.codehaus.org/browse/MASSEMBLY-192
>
> I'm continuing my testing past this to see if there are any other
> issues, though it looks fine.
>
> - Brett
>
> On 29/03/2007, at 2:59 AM, John Casey wrote:
>
> > Hi everyone,
> >
> > I wanted to call a vote to release a beta version of the new  
assembly
> > plugin. There are still some outstanding issues (though not  
as many

> > as jira
> > would have you believe; they just need tests), but I think  
we're at

> > around
> > 95-99% backward compatibility and the new features seem to be
> > working well.
> > It's been just sitting in SVN for quite awhile now, and many  
people

> > are
> > using it directly from there. I'd like to provide better support
> > for those
> > people, and start getting more feedback on exactly what's still
> > broken.
> >
> > The change list is pretty large, but is mainly concerned with
> > refactoring
> > the plugin away from the old monolithic approach to one that  
uses

> > phases to
> > handle the different descriptor sections, along with common task
> > classes to
> > handle behavior shared between phases.
> >
> > Road Map:
> >
> > http://jira.codehaus.org/secure/ReleaseNote.jspa?
> > projectId=11126&styleName=Html&version=12617
> >
> >
> > Tag:
> >
> > http://svn.apache.org/repos/asf/maven/plugins/tags/maven- 
assembly-

> > plugin-2.2-beta-1
> >
> > Staging repository:
> >
> > http://people.apache.org/~jdcasey/stage/repopeople.apache.org/%7Ejdcasey/stage/repo>

> >
> > Also, since this is just a beta, and there are some folks out  
there

> > waiting
> > on this release to release some of their own components, I'd  
like

> > to make
> > this a shorter vote; say, of around 24-36 hrs max. Regardless of
> > whether we
> > agree to do this in short order, I would like to get this  
release

> > out on
> > this vote, so don't let the timing affect your +1...if people
> > complain, I'll
> > just let it sit for the standard 72h.
> >
> > So, let's try for 24hrs. Please vote +1/+0/-1.
> >
> > Here's my +1.
> >
> > -john
>
>  
 
-

> 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: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Jason Dillon]

This is a general problem with the magical RELEASE version that  
plugins use... IMO this is an anti-feature and should be removed in  
general and force people to configure the plugin's version to help  
ensure that future releases of plugins don't break their builds.


--jason


On Mar 28, 2007, at 6:49 PM, John Casey wrote:

The real problem here is that as long as there are tags out there  
that don't
specify plugin versions, we have no mechanism for deprecating or  
breaking

api compat, regardless of the version (2.0 -> 2.1 -> 2.2 -> 99.0).

-j

On 3/28/07, John Casey <[EMAIL PROTECTED]> wrote:


MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it to  
the
tag...then we could roll another candidate, though I do want to  
resolve

Max's issue above as well.

Max: I'm tempted to say that we should look for decimal versions  
of common

octal expressions, then prefix the rest with '0' to ensure they're
interpreted as octal (unless they have 0x in front, that is).

Is that a decent solution?

-john

On 3/28/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> -1
>
> But it got really close :)
>
> Unfortunately, I found a regression, though it looks a simple  
one to

> fix: http://jira.codehaus.org/browse/MASSEMBLY-192
>
> I'm continuing my testing past this to see if there are any other
> issues, though it looks fine.
>
> - Brett
>
> On 29/03/2007, at 2:59 AM, John Casey wrote:
>
> > Hi everyone,
> >
> > I wanted to call a vote to release a beta version of the new  
assembly
> > plugin. There are still some outstanding issues (though not as  
many

> > as jira
> > would have you believe; they just need tests), but I think  
we're at

> > around
> > 95-99% backward compatibility and the new features seem to be
> > working well.
> > It's been just sitting in SVN for quite awhile now, and many  
people

> > are
> > using it directly from there. I'd like to provide better support
> > for those
> > people, and start getting more feedback on exactly what's still
> > broken.
> >
> > The change list is pretty large, but is mainly concerned with
> > refactoring
> > the plugin away from the old monolithic approach to one that uses
> > phases to
> > handle the different descriptor sections, along with common task
> > classes to
> > handle behavior shared between phases.
> >
> > Road Map:
> >
> > http://jira.codehaus.org/secure/ReleaseNote.jspa?
> > projectId=11126&styleName=Html&version=12617
> >
> >
> > Tag:
> >
> > http://svn.apache.org/repos/asf/maven/plugins/tags/maven- 
assembly-

> > plugin-2.2-beta-1
> >
> > Staging repository:
> >
> > http://people.apache.org/~jdcasey/stage/repopeople.apache.org/%7Ejdcasey/stage/repo>

> >
> > Also, since this is just a beta, and there are some folks out  
there

> > waiting
> > on this release to release some of their own components, I'd like
> > to make
> > this a shorter vote; say, of around 24-36 hrs max. Regardless of
> > whether we
> > agree to do this in short order, I would like to get this release
> > out on
> > this vote, so don't let the timing affect your +1...if people
> > complain, I'll
> > just let it sit for the standard 72h.
> >
> > So, let's try for 24hrs. Please vote +1/+0/-1.
> >
> > Here's my +1.
> >
> > -john
>
>  
-

> 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: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[John Casey]

The real problem here is that as long as there are tags out there that don't
specify plugin versions, we have no mechanism for deprecating or breaking
api compat, regardless of the version (2.0 -> 2.1 -> 2.2 -> 99.0).

-j

On 3/28/07, John Casey <[EMAIL PROTECTED]> wrote:


MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it to the
tag...then we could roll another candidate, though I do want to resolve
Max's issue above as well.

Max: I'm tempted to say that we should look for decimal versions of common
octal expressions, then prefix the rest with '0' to ensure they're
interpreted as octal (unless they have 0x in front, that is).

Is that a decent solution?

-john

On 3/28/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> -1
>
> But it got really close :)
>
> Unfortunately, I found a regression, though it looks a simple one to
> fix: http://jira.codehaus.org/browse/MASSEMBLY-192
>
> I'm continuing my testing past this to see if there are any other
> issues, though it looks fine.
>
> - Brett
>
> On 29/03/2007, at 2:59 AM, John Casey wrote:
>
> > Hi everyone,
> >
> > I wanted to call a vote to release a beta version of the new assembly
> > plugin. There are still some outstanding issues (though not as many
> > as jira
> > would have you believe; they just need tests), but I think we're at
> > around
> > 95-99% backward compatibility and the new features seem to be
> > working well.
> > It's been just sitting in SVN for quite awhile now, and many people
> > are
> > using it directly from there. I'd like to provide better support
> > for those
> > people, and start getting more feedback on exactly what's still
> > broken.
> >
> > The change list is pretty large, but is mainly concerned with
> > refactoring
> > the plugin away from the old monolithic approach to one that uses
> > phases to
> > handle the different descriptor sections, along with common task
> > classes to
> > handle behavior shared between phases.
> >
> > Road Map:
> >
> > http://jira.codehaus.org/secure/ReleaseNote.jspa?
> > projectId=11126&styleName=Html&version=12617
> >
> >
> > Tag:
> >
> > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-
> > plugin-2.2-beta-1
> >
> > Staging repository:
> >
> > 
http://people.apache.org/~jdcasey/stage/repo
> >
> > Also, since this is just a beta, and there are some folks out there
> > waiting
> > on this release to release some of their own components, I'd like
> > to make
> > this a shorter vote; say, of around 24-36 hrs max. Regardless of
> > whether we
> > agree to do this in short order, I would like to get this release
> > out on
> > this vote, so don't let the timing affect your +1...if people
> > complain, I'll
> > just let it sit for the standard 72h.
> >
> > So, let's try for 24hrs. Please vote +1/+0/-1.
> >
> > Here's my +1.
> >
> > -john
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[John Casey]

MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it to the
tag...then we could roll another candidate, though I do want to resolve
Max's issue above as well.

Max: I'm tempted to say that we should look for decimal versions of common
octal expressions, then prefix the rest with '0' to ensure they're
interpreted as octal (unless they have 0x in front, that is).

Is that a decent solution?

-john

On 3/28/07, Brett Porter <[EMAIL PROTECTED]> wrote:


-1

But it got really close :)

Unfortunately, I found a regression, though it looks a simple one to
fix: http://jira.codehaus.org/browse/MASSEMBLY-192

I'm continuing my testing past this to see if there are any other
issues, though it looks fine.

- Brett

On 29/03/2007, at 2:59 AM, John Casey wrote:

> Hi everyone,
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many
> as jira
> would have you believe; they just need tests), but I think we're at
> around
> 95-99% backward compatibility and the new features seem to be
> working well.
> It's been just sitting in SVN for quite awhile now, and many people
> are
> using it directly from there. I'd like to provide better support
> for those
> people, and start getting more feedback on exactly what's still
> broken.
>
> The change list is pretty large, but is mainly concerned with
> refactoring
> the plugin away from the old monolithic approach to one that uses
> phases to
> handle the different descriptor sections, along with common task
> classes to
> handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11126&styleName=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-
> plugin-2.2-beta-1
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo
>
> Also, since this is just a beta, and there are some folks out there
> waiting
> on this release to release some of their own components, I'd like
> to make
> this a shorter vote; say, of around 24-36 hrs max. Regardless of
> whether we
> agree to do this in short order, I would like to get this release
> out on
> this vote, so don't let the timing affect your +1...if people
> complain, I'll
> just let it sit for the standard 72h.
>
> So, let's try for 24hrs. Please vote +1/+0/-1.
>
> Here's my +1.
>
> -john

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

Re: [jira] Closed: (MASSEMBLY-192) regression in repository assembly

[Brett Porter]

Flagged, since I have on my list to review how assembly ITs do their  
thang.


Might take me up to a week :)

- Brett

On 29/03/2007, at 11:43 AM, John Casey (JIRA) wrote:



 [ http://jira.codehaus.org/browse/MASSEMBLY-192? 
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]


John Casey closed MASSEMBLY-192.


 Assignee: John Casey
   Resolution: Fixed
Fix Version/s: 2.2-beta-1

forgot an "implements" clause, it looks like.

Brett, would it be possible for you to simplify your config a bit  
and produce an integration test (just a project and verify script)  
that we could put in src/it to guard against this regression in  
future?




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

[discuss] Splitting the stable and unstable repositories

[Brett Porter]

Hi,

I didn't want to pin the assembly plugin vote to this, but it seemed  
like a good opportunity to bring this up.


I'd like to propose we split the stable repository from the unstable  
repository (which would be where alphas, betas and rcs get deployed),  
and make this a documented best practice.


This would not be a concept change in Maven (at least, yet - it could  
be something to consider in the versioning in future): it's simply  
two types of release repositories. The stable one would be included  
in Maven by default, the unstable/pre-release one would not. You'd  
have to add the repository to your project.


I would suggest this for future additions to central, but leave  
anything currently there in place for backwards compat.


I think this is a good all round concept, but there is a particular  
practical problem that we should do this for: unpinned plugin  
versions. In the specific example of the assembly plugin - if you  
don't request a version (ie, use latest release), or you said [2.1,),  
then you'll get the 2.2-beta-1 release which is presumably less  
stable than 2.1. The same rationalisation would apply to ranges used  
in any dependency, but thats the biggest use case I can think of that  
affects people today. It would allow us to do more regular test  
releases of the plugins.


Thoughts?

- Brett

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

Re: Adding default OSGi information to JARs

[Carlos Sanchez]

half here, half in felix-dev

I have made some improvements to Felix bundle plugin for manifest
generation that you can see here
https://issues.apache.org/jira/browse/FELIX-199

once that it's applied and hopefully released we'll give a try with
our own maven artifacts


On 3/28/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:

On 3/28/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> I'm working with the Felix guys to go through all these issues. As
> usual Maven would provide a default manifest that you could override
> with configuration in your pom.

Where is this conversation happening? I'd like to hear more about the details.

-Nathan

>
> On 3/28/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > On 3/28/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> > >
> > > We're just trying to help out the OSGi folks so that they aren't
> > > repackaging everything which is what they are doing. It's basically
> > > doing the minimum work so that JARs produced will function with OSGi
> > > containers. If it has no impact on normal users there's no real harm
> > > in trying to help. I just don't want Maven used as a vehicle to push
> > > OSGi down people's throats.
> > >
> > > Jason.
> >
> > I must concur with Jason's note of caution. Be very careful in this
> > realm. You can't just arbitrarily add OSGi entries to a manifest of
> > every build. OSGi entries must be defined very carefully, as they are
> > deployment descriptors and can have a significant impact on how a
> > bundle is consumed. There are many factors to take into consideration.
> >
> > For example, there are multiple ways to declare dependencies, you can
> > declare a dependency on a bundle, by name and you can declare a
> > dependency on a Java package, which abstracts you from a particular
> > packaging. Additionally, each dependency can be optional, meaning the
> > bundle can be started, even if that dependency isn't available. The
> > dependencies can be version-specific too, so a bundle can require a
> > specific version of a bundle or specific version of a Java package.
> > Note, though OSGi versions are similar to Maven2 versions, there are
> > some major conflicts, such as the interpretation of qualifiers.
> >
> > Once OSGi information is added to a JAR to make it a proper OSGi
> > bundle, those values make an API contract that must be strictly
> > adhered to.
> >
> > It's my opinion that OSGi enablement must be taken on by
> > component/project owners. I think that the only part the Maven
> > community should play here is adding OSGi support and making it easy.
> > The only other consideration might be to consider how Maven2 might be
> > OSGi hosted, but I'd be very surprised if this turned out as simple as
> > all Maven JARs adding "standard" manifest attributes.
> >
> > -Nathan Beyer
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>
> -
> 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]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Brett Porter]

-1

But it got really close :)

Unfortunately, I found a regression, though it looks a simple one to  
fix: http://jira.codehaus.org/browse/MASSEMBLY-192


I'm continuing my testing past this to see if there are any other  
issues, though it looks fine.


- Brett

On 29/03/2007, at 2:59 AM, John Casey wrote:


Hi everyone,

I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many  
as jira
would have you believe; they just need tests), but I think we're at  
around
95-99% backward compatibility and the new features seem to be  
working well.
It's been just sitting in SVN for quite awhile now, and many people  
are
using it directly from there. I'd like to provide better support  
for those
people, and start getting more feedback on exactly what's still  
broken.


The change list is pretty large, but is mainly concerned with  
refactoring
the plugin away from the old monolithic approach to one that uses  
phases to
handle the different descriptor sections, along with common task  
classes to

handle behavior shared between phases.

Road Map:

http://jira.codehaus.org/secure/ReleaseNote.jspa? 
projectId=11126&styleName=Html&version=12617



Tag:

http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly- 
plugin-2.2-beta-1


Staging repository:

http://people.apache.org/~jdcasey/stage/repo

Also, since this is just a beta, and there are some folks out there  
waiting
on this release to release some of their own components, I'd like  
to make
this a shorter vote; say, of around 24-36 hrs max. Regardless of  
whether we
agree to do this in short order, I would like to get this release  
out on
this vote, so don't let the timing affect your +1...if people  
complain, I'll

just let it sit for the standard 72h.

So, let's try for 24hrs. Please vote +1/+0/-1.

Here's my +1.

-john


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

Re: Adding default OSGi information to JARs

[Nathan Beyer]

On 3/28/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:

I'm working with the Felix guys to go through all these issues. As
usual Maven would provide a default manifest that you could override
with configuration in your pom.


Where is this conversation happening? I'd like to hear more about the details.

-Nathan



On 3/28/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> On 3/28/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> >
> > We're just trying to help out the OSGi folks so that they aren't
> > repackaging everything which is what they are doing. It's basically
> > doing the minimum work so that JARs produced will function with OSGi
> > containers. If it has no impact on normal users there's no real harm
> > in trying to help. I just don't want Maven used as a vehicle to push
> > OSGi down people's throats.
> >
> > Jason.
>
> I must concur with Jason's note of caution. Be very careful in this
> realm. You can't just arbitrarily add OSGi entries to a manifest of
> every build. OSGi entries must be defined very carefully, as they are
> deployment descriptors and can have a significant impact on how a
> bundle is consumed. There are many factors to take into consideration.
>
> For example, there are multiple ways to declare dependencies, you can
> declare a dependency on a bundle, by name and you can declare a
> dependency on a Java package, which abstracts you from a particular
> packaging. Additionally, each dependency can be optional, meaning the
> bundle can be started, even if that dependency isn't available. The
> dependencies can be version-specific too, so a bundle can require a
> specific version of a bundle or specific version of a Java package.
> Note, though OSGi versions are similar to Maven2 versions, there are
> some major conflicts, such as the interpretation of qualifiers.
>
> Once OSGi information is added to a JAR to make it a proper OSGi
> bundle, those values make an API contract that must be strictly
> adhered to.
>
> It's my opinion that OSGi enablement must be taken on by
> component/project owners. I think that the only part the Maven
> community should play here is adding OSGi support and making it easy.
> The only other consideration might be to consider how Maven2 might be
> OSGi hosted, but I'd be very surprised if this turned out as simple as
> all Maven JARs adding "standard" manifest attributes.
>
> -Nathan Beyer
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

-
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: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Max Bowsher]

John Casey wrote:
> Hi everyone,
> 
> I wanted to call a vote to release a beta version of the new assembly
> plugin.
...
> Road Map:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617
> 
> Tag:
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1
...
> So, let's try for 24hrs. Please vote +1/+0/-1.

I vote a non-binding hang-on-a-bit-and-let's-discuss-a-compatibility-issue.

I believe that the existing fix to MASSEMBLY-173 is not necessarily the
best one.

To recap:
In 2.1,  and  children of 
   and  elements were
processed by Integer.parseInt(x, 8). However the  children of
 elements were processed by Integer.parseInt(x).
In 2.2-beta-1, all these have been replaced with Integer.decode().

This means that in 2.1, elements in the first group were always
processed as octal, whilst  elements were always
processed as decimal.

In 2.2-beta-1, this has been changed so that everything depends on
whether a leading zero is used.

I don't think this is a good idea, because there are very likely many
existing assembly descriptors using octal modes without a leading zero,
because it has worked fine that way for a long time, and people are
accustomed to chmod, the prime example of an octal mode UI, not
requiring one.

The problem remains, what to do with the  element. As I
see it, possibilities are:

(1) Change to interpreting it as octal always, breaking old POMs.

(2) As (1), but allow some special hackery detecting modes which look
like the decimal representation of common octal modes, and treating them
as such. Examples would be 420 (644), 436 (664), 493 (755), 509 (775).

(3) Change to interpreting it dependent on the presence/absence of a
leading zero.


In my opinion, maintaining compatibility should be a high priority,
since as the release-plugin does not *actually* generate release-pom.xml
files, any compatibility break will break the build reproducibility of
many people's SCM tags.


Max.







signature.asc
Description: OpenPGP digital signature

Re: Adding default OSGi information to JARs

[Carlos Sanchez]

I'm working with the Felix guys to go through all these issues. As
usual Maven would provide a default manifest that you could override
with configuration in your pom.

On 3/28/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:

On 3/28/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> We're just trying to help out the OSGi folks so that they aren't
> repackaging everything which is what they are doing. It's basically
> doing the minimum work so that JARs produced will function with OSGi
> containers. If it has no impact on normal users there's no real harm
> in trying to help. I just don't want Maven used as a vehicle to push
> OSGi down people's throats.
>
> Jason.

I must concur with Jason's note of caution. Be very careful in this
realm. You can't just arbitrarily add OSGi entries to a manifest of
every build. OSGi entries must be defined very carefully, as they are
deployment descriptors and can have a significant impact on how a
bundle is consumed. There are many factors to take into consideration.

For example, there are multiple ways to declare dependencies, you can
declare a dependency on a bundle, by name and you can declare a
dependency on a Java package, which abstracts you from a particular
packaging. Additionally, each dependency can be optional, meaning the
bundle can be started, even if that dependency isn't available. The
dependencies can be version-specific too, so a bundle can require a
specific version of a bundle or specific version of a Java package.
Note, though OSGi versions are similar to Maven2 versions, there are
some major conflicts, such as the interpretation of qualifiers.

Once OSGi information is added to a JAR to make it a proper OSGi
bundle, those values make an API contract that must be strictly
adhered to.

It's my opinion that OSGi enablement must be taken on by
component/project owners. I think that the only part the Maven
community should play here is adding OSGi support and making it easy.
The only other consideration might be to consider how Maven2 might be
OSGi hosted, but I'd be very surprised if this turned out as simple as
all Maven JARs adding "standard" manifest attributes.

-Nathan Beyer

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: Adding default OSGi information to JARs

[Nathan Beyer]

On 3/28/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


We're just trying to help out the OSGi folks so that they aren't
repackaging everything which is what they are doing. It's basically
doing the minimum work so that JARs produced will function with OSGi
containers. If it has no impact on normal users there's no real harm
in trying to help. I just don't want Maven used as a vehicle to push
OSGi down people's throats.

Jason.


I must concur with Jason's note of caution. Be very careful in this
realm. You can't just arbitrarily add OSGi entries to a manifest of
every build. OSGi entries must be defined very carefully, as they are
deployment descriptors and can have a significant impact on how a
bundle is consumed. There are many factors to take into consideration.

For example, there are multiple ways to declare dependencies, you can
declare a dependency on a bundle, by name and you can declare a
dependency on a Java package, which abstracts you from a particular
packaging. Additionally, each dependency can be optional, meaning the
bundle can be started, even if that dependency isn't available. The
dependencies can be version-specific too, so a bundle can require a
specific version of a bundle or specific version of a Java package.
Note, though OSGi versions are similar to Maven2 versions, there are
some major conflicts, such as the interpretation of qualifiers.

Once OSGi information is added to a JAR to make it a proper OSGi
bundle, those values make an API contract that must be strictly
adhered to.

It's my opinion that OSGi enablement must be taken on by
component/project owners. I think that the only part the Maven
community should play here is adding OSGi support and making it easy.
The only other consideration might be to consider how Maven2 might be
OSGi hosted, but I'd be very surprised if this turned out as simple as
all Maven JARs adding "standard" manifest attributes.

-Nathan Beyer

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

Re: confluence (was: We're near the release of 1.0 final)

[John Casey]

I can't say that I care much one way or another, when it comes to moving all
doco from the codehaus wiki to cwiki or leaving it as-is...provided the
conversion is 100% successful, and cwiki is stable. The stability point is a
concern for me, since I've seen some pretty ugly messes with ASF infra in
the past.

Of bigger concern to me is the fact that the MAVEN space is such a mess...

One thing that is interesting is that wiki content wouldn't be affected by
confluence outages, since it's exported to the static pages...and I'm not
sure it's a great idea to have something like setup that between ASF and
codehaus...it's only adding moving parts that can fail.

Is there a reason I should get fired up about either outcome?

-john

On 3/28/07, Brett Porter <[EMAIL PROTECTED]> wrote:


(moving to main dev list as scope has increased)

On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:

>
> On 28 Mar 07, at 9:03 AM 28 Mar 07, Brett Porter wrote:
>
>>
>> On 28/03/2007, at 10:35 PM, Jason van Zyl wrote:
>>
>>>
>>> No, please don't fragment even more our documentation situation.
>>> We have the stuff in SVN, Confluence users spaces and developer
>>> works spaces. The autoexport could easily be setup with the space
>>> we have if it isn't already.
>>
>> This documentation is already in its own space, so it's low
>> impact. I believe it is not currently editable by users, and only
>> a couple of pages. This does no harm to the current situation, and
>> gives us the opportunity to try it out.
>>
>> Reasons I believe cwiki is a better choice:
>> - autoexport is already configured. No work to do.
>> - We have a greater level of access than we do at codehaus.
>> - No banner ads.
>> - It's back on the apache.org domain.
>>
>> I don't see any downside...
>>
>
> Other then the severe one one of fragmenting our documentation. Do
> what you like.

On 28/03/2007, at 11:16 PM, Emmanuel Venisse wrote:
> We'd can use the codehaus wiki for our dev/design pages and for
> users pages we'd can use the cwiki with the autoexport and the
> maven css to include the content in our site.
> I think it would be good to do it for our other products, so we'd
> can create easily cookbooks, but this ML isn't the place to discuss
> it ;)

Similar to what Emmanuel suggested, how about we move *all* the
current spaces to cwiki, avoiding any further fragmentation, and in
fact removing the current fragmentation between the apache site and
the codehaus confluence, as well as getting all of the above benefits?

Before biting the bullet we can do a trial with this single SCM page.

What do folks think?

Cheers,
Brett

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

Re: confluence (was: We're near the release of 1.0 final)

[Brett Porter]

(moving to main dev list as scope has increased)

On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:



On 28 Mar 07, at 9:03 AM 28 Mar 07, Brett Porter wrote:



On 28/03/2007, at 10:35 PM, Jason van Zyl wrote:



No, please don't fragment even more our documentation situation.  
We have the stuff in SVN, Confluence users spaces and developer  
works spaces. The autoexport could easily be setup with the space  
we have if it isn't already.


This documentation is already in its own space, so it's low  
impact. I believe it is not currently editable by users, and only  
a couple of pages. This does no harm to the current situation, and  
gives us the opportunity to try it out.


Reasons I believe cwiki is a better choice:
- autoexport is already configured. No work to do.
- We have a greater level of access than we do at codehaus.
- No banner ads.
- It's back on the apache.org domain.

I don't see any downside...



Other then the severe one one of fragmenting our documentation. Do  
what you like.


On 28/03/2007, at 11:16 PM, Emmanuel Venisse wrote:
We'd can use the codehaus wiki for our dev/design pages and for  
users pages we'd can use the cwiki with the autoexport and the  
maven css to include the content in our site.
I think it would be good to do it for our other products, so we'd  
can create easily cookbooks, but this ML isn't the place to discuss  
it ;)


Similar to what Emmanuel suggested, how about we move *all* the  
current spaces to cwiki, avoiding any further fragmentation, and in  
fact removing the current fragmentation between the apache site and  
the codehaus confluence, as well as getting all of the above benefits?


Before biting the bullet we can do a trial with this single SCM page.

What do folks think?

Cheers,
Brett

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

Re: [vote] maven-app-configuration and maven-shared-component parent release

[Jesse McConnell]

ok, I redid the release using the parent version of 7 so if its ok
with folks I would like to just keep this vote ongoing...the only
difference is the 8->7 in the parent version

I republished the artifacts to the same directory and smoked the old
ones, thanks for noticing that dennis

jesse

On 3/28/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:

oh oh, I see, that was the old artifact name...nevermind on the parent
part then, I'll fix that up and point it to 7 then

jesse

On 3/28/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:
> has that been pushed out anywhere?
>
> 
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/shared/shared-components-parent/
>
> I only see up to 2 there...
>
> On 3/28/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> > Jesse McConnell wrote:
> > > As part of the prepwork for getting an actual continuum alpha release
> > > out I need to get a few more dependencies released, one of them is the
> > > maven-app-configuration.  And since the currently released parent
> > > version is out of date with regards to the new release setup I have to
> > > release that as well.
> >
> > Jesse,
> >
> > Before I released maven-plugin-tools I released
> > maven-shared-components-7, on March 9. I can't see what is missing from
> > that version. Do you really need a version 8?
> >
> > > Tags:
> > > 
https://svn.apache.org/repos/asf/maven/shared/tags/maven-app-configuration-1.0
> > >
> > >
> > > Staged at:
> > > http://people.apache.org/~jmcconnell/org/apache/maven/shared/
> > >
> > > This would be an initial release of these fairly simple components,
> > > they are primarily to bring some unity in configuration elements
> > > between archiva and continuum right now.
> > >
> > > Vote is open for 72 hours.
> > >
> > > +1
> > >
> >
> >
> > --
> > Dennis Lundberg
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> jesse mcconnell
> [EMAIL PROTECTED]
>


--
jesse mcconnell
[EMAIL PROTECTED]




--
jesse mcconnell
[EMAIL PROTECTED]

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

Re: [vote][m1] release modello plugin 1.0

[Arnaud HERITIER]

ping PMCs

Thx

Arnaud

On 26/03/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:


Hi,

  I think that it is the time to release the modello plugin for maven 1.xin 
version
1.0.
  This plugin allows to use modello (1.0-alpha-15) inside a maven 1.xbuild and 
is used to create our maven-model classes for maven
1.x.
  You can find for this plugin a complete documentation 
[http://people.apache.org/~aheritier/m1-plugins-stage-sites/maven-1.x/plugins/modello/index.html

]
and you can install it with :
maven plugin:download -
Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
 -DgroupId=maven
-DartifactId=maven-modello-plugin -Dversion=1.0-SNAPSHOT
  I propose also that we move out of the sandbox this plugin to bundle it
in the next distribution.
  It's not a real risk because it is completely independent of the others
plugins. I'll create a new Jira project for this plugin when the vote will
be ended.
  The list of changes since the last alpha is available here : 
http://people.apache.org/~aheritier/m1-plugins-stage-sites/maven-1.x/plugins/modello/changes-report.html



My votes :
+1 for the release
+1 to move it in the distribution

Arnaud

Re: maven-jdee-plugin for emacs users

[Daniel Kulp]

James,

This is definitely something that would be better put in the maven 
repository as an eventual official Maven plugin.   My suggestion would 
be to create a new directory in the maven plugins sandbox: (all apache 
committers have access)
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/
and work on it there.   Obviously use the proper maven plugin parent poms 
and style guides and stuff instead of the CXF ones.  (and make it JDK 
1.4 compliant)

To answer your generated sources question:
The buildSourceRoots would have them if your plugin executes after 
whatever phase adds those.Thus, if you run:
mvn process-test-sources jdee:jdee
it should pick up all the generated source directories.   That said, you 
could look into the eclipse plugin a bit.   It actually invokes the 
lifecycle up to the process-sources phase so it would get the generated 
sources.   It wouldn't get generated tests though which is why use the 
setup.eclipse profile that forces it to run in the process-test-sources 
phase instead.

Anyway, nice job.

Dan



On Wednesday 28 March 2007 02:07, James Mao wrote:
> Hi,
>
> I have checked in a maven-jdee-plugin for emacs jdee users.
>
> How to config:
>
> 1. > cd /cxf/tools/jdee
> 2. > mvn install
> 3. modify the ~/.m2/settings.xml  add the following block
> 
> org.apache.cxf.maven
> 
> 4. > cd /cxf
> 5. > mvn jdee:jdee  # to generate the jdee prj.el
>
> If you want to clean
>
>  > mvn jdee:clean
>
> I don't know how to include the generated source code,
> The MavenProject.getCompileSourceRoots() should get all the source
> code include the generated ones, but unfortunately it doesn't.
> I guess the plugin must attach one of the general build phase to
> include the generated ones.
>
> Anyway the code completion and source navigation should works in
> general in our cxf code base.
>
> Enjoy!
> James.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

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

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Daniel Kulp]

+1  

LOTS of us have been waiting for this one.

Thanks!
Dan

On Wednesday 28 March 2007 12:59, John Casey wrote:
> Hi everyone,
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many as
> jira would have you believe; they just need tests), but I think we're
> at around 95-99% backward compatibility and the new features seem to
> be working well. It's been just sitting in SVN for quite awhile now,
> and many people are using it directly from there. I'd like to provide
> better support for those people, and start getting more feedback on
> exactly what's still broken.
>
> The change list is pretty large, but is mainly concerned with
> refactoring the plugin away from the old monolithic approach to one
> that uses phases to handle the different descriptor sections, along
> with common task classes to handle behavior shared between phases.
>
> Road Map:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&style
>Name=Html&version=12617
>
>
> Tag:
>
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plug
>in-2.2-beta-1
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo
>
> Also, since this is just a beta, and there are some folks out there
> waiting on this release to release some of their own components, I'd
> like to make this a shorter vote; say, of around 24-36 hrs max.
> Regardless of whether we agree to do this in short order, I would like
> to get this release out on this vote, so don't let the timing affect
> your +1...if people complain, I'll just let it sit for the standard
> 72h.
>
> So, let's try for 24hrs. Please vote +1/+0/-1.
>
> Here's my +1.
>
> -john

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

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

Re: [VOTE] Release Maven 2.0.6

[Jason van Zyl]

On 28 Mar 07, at 11:32 AM 28 Mar 07, Rollo, Dan wrote:

Any plans to also release an update to maven2 ant tasks and/or  
embedder

in this go 'round?


Yes, I realized a snapshot and already posted about releasing them  
after the 2.0.6 release.


They are sitting here:

http://idisk.maven.org/jvanzyl/Public/maven/

Jason.


If not, any idea how/when these might be updated?

Last I saw, the embedder was basically dead until 2.1 is released, and
I'm wondering if the ant dep tasks are in the same boat.

Thanks,
Dan

-Original Message-
From: Eric Redmond [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 12:16 AM
To: Maven Developers List
Subject: Re: [VOTE] Release Maven 2.0.6

+1

On 3/27/07, Brett Porter <[EMAIL PROTECTED]> wrote:


Tested ok here.

+1

On 27/03/2007, at 12:55 PM, Jason van Zyl wrote:


Hi,

The roadmap is here:

http://jira.codehaus.org/secure/IssueNavigator.jspa?
reset=true&pid=10500&fixfor=13010

The tag is here:

http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/

Staging repository:

http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/

And the distros you are interested in are here:

http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/
org/apache/maven/maven-core/2.0.6/

Thanks,

Jason.




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





--
Eric Redmond
http://codehaus.org/~eredmond

--
This e-mail and any files transmitted with it may contain  
privileged or confidential information.
It is solely for use by the individual for whom it is intended,  
even if addressed incorrectly.
If you received this e-mail in error, please notify the sender; do  
not disclose, copy, distribute,
or take any action in reliance on the contents of this information;  
and delete it from

your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.
--

-
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: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Tomasz Pik]

On 3/28/07, John Casey <[EMAIL PROTECTED]> wrote:

Hi everyone,

I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as jira
would have you believe; they just need tests), but I think we're at around
95-99% backward compatibility and the new features seem to be working well.


[...]


So, let's try for 24hrs. Please vote +1/+0/-1.


Non-binding +1.

Thanks!
Tomek

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

Re: [vote] maven-app-configuration and maven-shared-component parent release

[Jesse McConnell]

oh oh, I see, that was the old artifact name...nevermind on the parent
part then, I'll fix that up and point it to 7 then

jesse

On 3/28/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:

has that been pushed out anywhere?

http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/shared/shared-components-parent/

I only see up to 2 there...

On 3/28/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> Jesse McConnell wrote:
> > As part of the prepwork for getting an actual continuum alpha release
> > out I need to get a few more dependencies released, one of them is the
> > maven-app-configuration.  And since the currently released parent
> > version is out of date with regards to the new release setup I have to
> > release that as well.
>
> Jesse,
>
> Before I released maven-plugin-tools I released
> maven-shared-components-7, on March 9. I can't see what is missing from
> that version. Do you really need a version 8?
>
> > Tags:
> > 
https://svn.apache.org/repos/asf/maven/shared/tags/maven-app-configuration-1.0
> >
> >
> > Staged at:
> > http://people.apache.org/~jmcconnell/org/apache/maven/shared/
> >
> > This would be an initial release of these fairly simple components,
> > they are primarily to bring some unity in configuration elements
> > between archiva and continuum right now.
> >
> > Vote is open for 72 hours.
> >
> > +1
> >
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
jesse mcconnell
[EMAIL PROTECTED]




--
jesse mcconnell
[EMAIL PROTECTED]

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

Re: [vote] maven-app-configuration and maven-shared-component parent release

[Jesse McConnell]

has that been pushed out anywhere?

http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/shared/shared-components-parent/

I only see up to 2 there...

On 3/28/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

Jesse McConnell wrote:
> As part of the prepwork for getting an actual continuum alpha release
> out I need to get a few more dependencies released, one of them is the
> maven-app-configuration.  And since the currently released parent
> version is out of date with regards to the new release setup I have to
> release that as well.

Jesse,

Before I released maven-plugin-tools I released
maven-shared-components-7, on March 9. I can't see what is missing from
that version. Do you really need a version 8?

> Tags:
> https://svn.apache.org/repos/asf/maven/shared/tags/maven-app-configuration-1.0
>
>
> Staged at:
> http://people.apache.org/~jmcconnell/org/apache/maven/shared/
>
> This would be an initial release of these fairly simple components,
> they are primarily to bring some unity in configuration elements
> between archiva and continuum right now.
>
> Vote is open for 72 hours.
>
> +1
>


--
Dennis Lundberg

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





--
jesse mcconnell
[EMAIL PROTECTED]

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

RE: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Brian E. Fox]

+1

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 28, 2007 12:59 PM
To: Maven Developers List
Subject: [vote] Release 2.2-beta-1 of maven-assembly-plugin

Hi everyone,

I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as
jira would have you believe; they just need tests), but I think we're at
around 95-99% backward compatibility and the new features seem to be
working well.
It's been just sitting in SVN for quite awhile now, and many people are
using it directly from there. I'd like to provide better support for
those people, and start getting more feedback on exactly what's still
broken.

The change list is pretty large, but is mainly concerned with
refactoring the plugin away from the old monolithic approach to one that
uses phases to handle the different descriptor sections, along with
common task classes to handle behavior shared between phases.

Road Map:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleNa
me=Html&version=12617


Tag:

http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin
-2.2-beta-1

Staging repository:

http://people.apache.org/~jdcasey/stage/repo

Also, since this is just a beta, and there are some folks out there
waiting on this release to release some of their own components, I'd
like to make this a shorter vote; say, of around 24-36 hrs max.
Regardless of whether we agree to do this in short order, I would like
to get this release out on this vote, so don't let the timing affect
your +1...if people complain, I'll just let it sit for the standard 72h.

So, let's try for 24hrs. Please vote +1/+0/-1.

Here's my +1.

-john

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

Re: [vote] maven-app-configuration and maven-shared-component parent release

[Dennis Lundberg]

Jesse McConnell wrote:

As part of the prepwork for getting an actual continuum alpha release
out I need to get a few more dependencies released, one of them is the
maven-app-configuration.  And since the currently released parent
version is out of date with regards to the new release setup I have to
release that as well.


Jesse,

Before I released maven-plugin-tools I released 
maven-shared-components-7, on March 9. I can't see what is missing from 
that version. Do you really need a version 8?



Tags:
https://svn.apache.org/repos/asf/maven/shared/tags/maven-app-configuration-1.0 



Staged at:
http://people.apache.org/~jmcconnell/org/apache/maven/shared/

This would be an initial release of these fairly simple components,
they are primarily to bring some unity in configuration elements
between archiva and continuum right now.

Vote is open for 72 hours.

+1




--
Dennis Lundberg

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

Re: [VOTE] Release Maven 2.0.6

[Joakim Erdfelt]

+1 (a little late)

- Joakim

Jason van Zyl wrote:
> Hi,
>
> The roadmap is here:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&fixfor=13010
>
>
> The tag is here:
>
> http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/
>
> Staging repository:
>
> http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/
>
> And the distros you are interested in are here:
>
> http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/org/apache/maven/maven-core/2.0.6/
>
>
> Thanks,
>
> Jason.
>
>
>
> -
> 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: HowTo avoid version number in filenames

[Joakim Erdfelt]

The fact that install / deploy process maintains the filename with a
version in it is simple.

The repository is to be thought of as a database.
The local repository is to be thought of as a remote repository cache.

The repository database *needs* versioning.

The plugins that bundle the artifacts within other files (such a
assembly, war, ear, etc...) honor the  setting when working
on the artifacts outside of the Repository database.

- Joakim

Stephane Nicoll wrote:
> Hi,
>
> On 3/28/07, Franz Allan Valencia See <[EMAIL PROTECTED]> wrote:
>> Good day to you, Dheeraj,
>>
>> Try
>>
>> 
>>   ...
>>   
>> ${artifactId}
>> ...
>>   
>>   ...
>> 
>>
>> By default, the value of finalName is "${artifactId}-${version}" (
>> without
>> the quotes ) which every pom inherits from the super pom ( see [1] ).
>
> This is not honored by the deploy/install plugins so I am not sure
> it's fixing anything.
>
>>
>> ..btw, you might want to try asking in the maven users list next time
>> to get
>> a faster response :)
>
> +1
>
> Stéphane
>
>
>>
>> Cheers,
>> Franz
>>
>> [1]
>> http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
>>
>> On 3/27/07, Pant, Dheeraj <[EMAIL PROTECTED]> wrote:
>> >
>> > Hi,
>> >
>> > Using Maven generates all the artifacts (jars/wars/ears)
>> > with a unique filename -.. How do we remove
>> > the version number from the filenames? I need a generic way to do
>> this,
>> > because we have many sub-modules and would like to have a common
>> > solution that can be reused for every module.
>> >
>> >
>> >
>> > I tried the following things:
>> >
>> > 1. For ear, Maven allows to rename the modules.
>> >
>> > 2. Using an ant task, rename each jar/war/ear after it gets packaged.
>> >
>> >
>> >
>> > However, still classpath within the MANIFEST files (generated using
>> > Maven) refers to unique filenames including their version numbers. We
>> > don't want to hardcode our manifest files. I tried specifying project
>> > specific modules as system dependency - did not work.
>> >
>> >
>> >
>> > Is there a way out?
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Dheeraj.
>> >
>> >
>> >
>> >
>> >
>> > -
>> > This message and any attachments are intended only for the use of
>> > the addressee and may contain information that is privileged and
>> > confidential. If the reader of the message is not the intended
>> > recipient or an authorized representative of the intended
>> > recipient, you are hereby notified that any dissemination of this
>> > communication is strictly prohibited. If you have received this
>> > communication in error, notify the sender immediately by return
>> > email and delete the message and any attachments from your system.
>>
>
> -
> 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: [vote] maven-app-configuration and maven-shared-component parent release

[Joakim Erdfelt]

+1

- Joakim

Jesse McConnell wrote:
> As part of the prepwork for getting an actual continuum alpha release
> out I need to get a few more dependencies released, one of them is the
> maven-app-configuration.  And since the currently released parent
> version is out of date with regards to the new release setup I have to
> release that as well.
>
> Tags:
> https://svn.apache.org/repos/asf/maven/shared/tags/maven-app-configuration-1.0
>
>
> Staged at:
> http://people.apache.org/~jmcconnell/org/apache/maven/shared/
>
> This would be an initial release of these fairly simple components,
> they are primarily to bring some unity in configuration elements
> between archiva and continuum right now.
>
> Vote is open for 72 hours.
>
> +1
>


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

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[John Casey]

I've moved the closed issues out of the 2.2 version in JIRA, into a separate
2.2-beta-1 version:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=13338

On 3/28/07, Richard van der Hoff <[EMAIL PROTECTED]> wrote:


Yes! Please! Oh god, yes

John Casey wrote:
> Hi everyone,
>
> I wanted to call a vote to release a beta version of the new assembly
> plugin. There are still some outstanding issues (though not as many as
jira
> would have you believe; they just need tests), but I think we're at
around
> 95-99% backward compatibility and the new features seem to be working
well.
> It's been just sitting in SVN for quite awhile now, and many people are
> using it directly from there. I'd like to provide better support for
those
> people, and start getting more feedback on exactly what's still broken.
>
> The change list is pretty large, but is mainly concerned with
refactoring
> the plugin away from the old monolithic approach to one that uses phases
to
> handle the different descriptor sections, along with common task classes
to
> handle behavior shared between phases.
>
> Road Map:
>
>
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617
>
>
>
> Tag:
>
>
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1
>
>
> Staging repository:
>
> http://people.apache.org/~jdcasey/stage/repo
>
> Also, since this is just a beta, and there are some folks out there
waiting
> on this release to release some of their own components, I'd like to
make
> this a shorter vote; say, of around 24-36 hrs max. Regardless of whether
we
> agree to do this in short order, I would like to get this release out on
> this vote, so don't let the timing affect your +1...if people complain,
> I'll
> just let it sit for the standard 72h.
>
> So, let's try for 24hrs. Please vote +1/+0/-1.
>
> Here's my +1.
>
> -john
>


--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

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

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Richard van der Hoff]

Yes! Please! Oh god, yes

John Casey wrote:

Hi everyone,

I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as jira
would have you believe; they just need tests), but I think we're at around
95-99% backward compatibility and the new features seem to be working well.
It's been just sitting in SVN for quite awhile now, and many people are
using it directly from there. I'd like to provide better support for those
people, and start getting more feedback on exactly what's still broken.

The change list is pretty large, but is mainly concerned with refactoring
the plugin away from the old monolithic approach to one that uses phases to
handle the different descriptor sections, along with common task classes to
handle behavior shared between phases.

Road Map:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617 




Tag:

http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1 



Staging repository:

http://people.apache.org/~jdcasey/stage/repo

Also, since this is just a beta, and there are some folks out there waiting
on this release to release some of their own components, I'd like to make
this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we
agree to do this in short order, I would like to get this release out on
this vote, so don't let the timing affect your +1...if people complain, 
I'll

just let it sit for the standard 72h.

So, let's try for 24hrs. Please vote +1/+0/-1.

Here's my +1.

-john




--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

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

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Stephane Nicoll]

+1

We're using the SNAPSHOT locally for many weeks now and all goes well.

Thanks,
Stéphane

On 3/28/07, John Casey <[EMAIL PROTECTED]> wrote:

Hi everyone,

I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as jira
would have you believe; they just need tests), but I think we're at around
95-99% backward compatibility and the new features seem to be working well.
It's been just sitting in SVN for quite awhile now, and many people are
using it directly from there. I'd like to provide better support for those
people, and start getting more feedback on exactly what's still broken.

The change list is pretty large, but is mainly concerned with refactoring
the plugin away from the old monolithic approach to one that uses phases to
handle the different descriptor sections, along with common task classes to
handle behavior shared between phases.

Road Map:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617


Tag:

http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1

Staging repository:

http://people.apache.org/~jdcasey/stage/repo

Also, since this is just a beta, and there are some folks out there waiting
on this release to release some of their own components, I'd like to make
this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we
agree to do this in short order, I would like to get this release out on
this vote, so don't let the timing affect your +1...if people complain, I'll
just let it sit for the standard 72h.

So, let's try for 24hrs. Please vote +1/+0/-1.

Here's my +1.

-john



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

Re: [vote] maven-app-configuration and maven-shared-component parent release

[John Casey]

+1

On 3/28/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


+1

Emmanuel

Jesse McConnell a écrit :
> As part of the prepwork for getting an actual continuum alpha release
> out I need to get a few more dependencies released, one of them is the
> maven-app-configuration.  And since the currently released parent
> version is out of date with regards to the new release setup I have to
> release that as well.
>
> Tags:
>
https://svn.apache.org/repos/asf/maven/shared/tags/maven-app-configuration-1.0
>
>
> Staged at:
> http://people.apache.org/~jmcconnell/org/apache/maven/shared/
>
> This would be an initial release of these fairly simple components,
> they are primarily to bring some unity in configuration elements
> between archiva and continuum right now.
>
> Vote is open for 72 hours.
>
> +1
>


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

[vote] Release 2.2-beta-1 of maven-assembly-plugin

[John Casey]

Hi everyone,

I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as jira
would have you believe; they just need tests), but I think we're at around
95-99% backward compatibility and the new features seem to be working well.
It's been just sitting in SVN for quite awhile now, and many people are
using it directly from there. I'd like to provide better support for those
people, and start getting more feedback on exactly what's still broken.

The change list is pretty large, but is mainly concerned with refactoring
the plugin away from the old monolithic approach to one that uses phases to
handle the different descriptor sections, along with common task classes to
handle behavior shared between phases.

Road Map:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=12617


Tag:

http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1

Staging repository:

http://people.apache.org/~jdcasey/stage/repo

Also, since this is just a beta, and there are some folks out there waiting
on this release to release some of their own components, I'd like to make
this a shorter vote; say, of around 24-36 hrs max. Regardless of whether we
agree to do this in short order, I would like to get this release out on
this vote, so don't let the timing affect your +1...if people complain, I'll
just let it sit for the standard 72h.

So, let's try for 24hrs. Please vote +1/+0/-1.

Here's my +1.

-john

Re: Adding default OSGi information to JARs

[Carlos Sanchez]

as soon as https://issues.apache.org/jira/browse/FELIX-199 gets
applied anybody can add the "manifest" goal and get the OSGi manifest
in the jar.

On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:

2007/3/28, Carlos Sanchez <[EMAIL PROTECTED]>:
> > It would be great if that could be available in 2.0.x version of
> > Maven. We are too far from 2.1 version.
> you will always have the option to add a plugin to your pom that will
> generate the OSGi manifest (the maven-bundle-plugin from Apache
> Felix). We are talking about 2.1 automatically invoking that plugin.

This is the way I'm doing now, invoking explicitly bundle packaging of
maven-bundle-plugin.

But I think to all these Apache commons-* projects that could be
automatically build with OSGi manifest entries.
If they agree, OSGi information will be automatically added as soon as
Maven will provide officially this feature.
So the longer we wait for Maven 2.1, the longer we have to package
ourself these projects.

Anyway, it's worth waiting for this feature which it's better that nothing :)

Damien

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: Adding default OSGi information to JARs

[Damien Lecan]

2007/3/28, Carlos Sanchez <[EMAIL PROTECTED]>:

> It would be great if that could be available in 2.0.x version of
> Maven. We are too far from 2.1 version.
you will always have the option to add a plugin to your pom that will
generate the OSGi manifest (the maven-bundle-plugin from Apache
Felix). We are talking about 2.1 automatically invoking that plugin.


This is the way I'm doing now, invoking explicitly bundle packaging of
maven-bundle-plugin.

But I think to all these Apache commons-* projects that could be
automatically build with OSGi manifest entries.
If they agree, OSGi information will be automatically added as soon as
Maven will provide officially this feature.
So the longer we wait for Maven 2.1, the longer we have to package
ourself these projects.

Anyway, it's worth waiting for this feature which it's better that nothing :)

Damien

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

Re: Adding default OSGi information to JARs

[Carlos Sanchez]

On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:

> > How this will be done ?
> At first by putting an innocuous plugin in the lifecycle, or in 2.1
> with extensions in Plexus it will be an extension to the JAR plugin
> that populates manifest information.

It would be great if that could be available in 2.0.x version of
Maven. We are too far from 2.1 version.



you will always have the option to add a plugin to your pom that will
generate the OSGi manifest (the maven-bundle-plugin from Apache
Felix). We are talking about 2.1 automatically invoking that plugin.



> > Will it be active by default ?
> If we decide that it's non-invasive and doesn't significantly
> increase the time of anyone's builds then I see so harm.

Ok I understand, but you didn't answer my (not clear) question : if
OSGi packaging is fast enough, will OSGi manifest entries be
transparently added to every maven-build jars ?



in 2.1 maybe, in the meantime you just need to add a plugin




Or will it be an OSGi developer option, that will never be known and
used by other common people ?

Thanks

Damien

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

RE: [VOTE] Release Maven 2.0.6

[Rollo, Dan]

Any plans to also release an update to maven2 ant tasks and/or embedder
in this go 'round?
If not, any idea how/when these might be updated?

Last I saw, the embedder was basically dead until 2.1 is released, and
I'm wondering if the ant dep tasks are in the same boat.

Thanks,
Dan 

-Original Message-
From: Eric Redmond [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 28, 2007 12:16 AM
To: Maven Developers List
Subject: Re: [VOTE] Release Maven 2.0.6

+1

On 3/27/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> Tested ok here.
>
> +1
>
> On 27/03/2007, at 12:55 PM, Jason van Zyl wrote:
>
> > Hi,
> >
> > The roadmap is here:
> >
> > http://jira.codehaus.org/secure/IssueNavigator.jspa?
> > reset=true&pid=10500&fixfor=13010
> >
> > The tag is here:
> >
> > http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/
> >
> > Staging repository:
> >
> > http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/
> >
> > And the distros you are interested in are here:
> >
> > http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/
> > org/apache/maven/maven-core/2.0.6/
> >
> > Thanks,
> >
> > Jason.
> >
> >
> >
> > 
> > - 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]
>
>


--
Eric Redmond
http://codehaus.org/~eredmond

--
This e-mail and any files transmitted with it may contain privileged or 
confidential information.
It is solely for use by the individual for whom it is intended, even if 
addressed incorrectly.
If you received this e-mail in error, please notify the sender; do not 
disclose, copy, distribute,
or take any action in reliance on the contents of this information; and delete 
it from
your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.
--

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

Re: [m2] findbugs xml parser

[dvicente]

i used the findbugs-maven-plugin in 1.0.0.

i have uploaded my findbugs xml result file.

http://www.nabble.com/file/7482/findbugs.xml findbugs.xml 

but it will be great if findbugs (not the maven plugin ) can read his own
analysis result file and that we can
navigate in with the findbugs API





Garvin LeClaire-2 wrote:
> 
> Which version of the Findbugs plugin are you using?
> Are you able to send me the findbugs.xml file?
> 
> 
> 
> 
> -- 
> Regards,
> 
> 
> Garvin LeClaire
> [EMAIL PROTECTED]
> 
> 
> 
> 
> On 3/28/07, dvicente <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hi,
>>
>> for my dashboard-maven-plugin, i want to parse the xml result file of
>> findbugs.
>>
>> Does anyone know if exist a parser in the API to retreive all objects
>> structure without to parse the file as a simple xml file ?
>>
>> the findbugs-maven-plugin generate xml file in wrong format .
>>
>> it generates messages as "Error analyzing public void " where init
>> is
>> a method and do a parseException.
>>
>> Does anyone know to correct that ?
>> --
>> View this message in context:
>> http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9710627
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9714967
Sent from the Maven Developers mailing list archive at Nabble.com.


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

Re: Adding default OSGi information to JARs

[Jason van Zyl]

On 28 Mar 07, at 9:27 AM 28 Mar 07, Kaloyan Enimanev wrote:


On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:

> > How this will be done ?
> At first by putting an innocuous plugin in the lifecycle, or in 2.1
> with extensions in Plexus it will be an extension to the JAR plugin
> that populates manifest information.

It would be great if that could be available in 2.0.x version of
Maven. We are too far from 2.1 version.

> > Will it be active by default ?
> If we decide that it's non-invasive and doesn't significantly
> increase the time of anyone's builds then I see so harm.

Ok I understand, but you didn't answer my (not clear) question : if
OSGi packaging is fast enough, will OSGi manifest entries be
transparently added to every maven-build jars ?

Or will it be an OSGi developer option, that will never be known and
used by other common people ?


IMHO this should depend on the type of the artifact i.e. the OSGI
bundles should be recognizable as such in the way we recognize EJB's
or WAR files.

This will provide a clear way to determine whether an artifact needs
OSGI specific headers or not.



We're just trying to help out the OSGi folks so that they aren't  
repackaging everything which is what they are doing. It's basically  
doing the minimum work so that JARs produced will function with OSGi  
containers. If it has no impact on normal users there's no real harm  
in trying to help. I just don't want Maven used as a vehicle to push  
OSGi down people's throats.


Jason.


best regards,
 Kaloyan



Thanks

Damien

-
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: [jira] Moved: (MANTTASKS-41) type attribute of artifact:dependencies doesn't work for indirect dependencies

[Jason van Zyl]

On 28 Mar 07, at 9:11 AM 28 Mar 07, Brett Porter wrote:


Jason,

Can you set up the released versions for these before moving more  
issues so that affects versions, etc are retained?


I think most of those are so unmaintained it doesn't matter. I'll be  
going through them, as they are only 40, and sort/categorize them.


No one has looked at them in ages and I doubt anything matches anyway.

Jason.

I only see 1.0-alpha-1 in there at the moment, and it doesn't make  
much sense to go backwards.


I've adjusted the project configuration to be standard maven style  
(workflow, creation screen).


We should also move the old issues out of MNG so they remain  
together and remove the component.


Let me know if I can help with any of these.

Cheers,
Brett

On 28/03/2007, at 11:01 PM, Jason van Zyl (JIRA) wrote:



 [ http://jira.codehaus.org/browse/MANTTASKS-41? 
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]


Jason van Zyl moved MNG-1542 to MANTTASKS-41:
-

Complexity:   (was: Intermediate)
   Key: MANTTASKS-41  (was: MNG-1542)
   Project: Maven 2.x Ant Tasks  (was: Maven 2)
  Workflow: jira  (was: Maven New)

type attribute of artifact:dependencies doesn't work for indirect  
dependencies
 
--


Key: MANTTASKS-41
URL: http://jira.codehaus.org/browse/MANTTASKS-41
Project: Maven 2.x Ant Tasks
 Issue Type: Sub-task
 Components: Ant tasks
   Affects Versions: 2.0
   Reporter: Tomislav Bodor
Fix For: 2.1.x

Attachments: build.xml, pom.xml


It appears that the type filter doesn't work properly with  
indirect dependencies. It doesn't look like an issue with the  
TypeArtifactFilter itself, but somewhere deeper. However, it's  
related to this feature, so here it is...
The problem manifests with transitive dependencies that are of  
different type, e.g. a war artefact depends on a jar library.  
Whatever the type in that case (jar or war), the dependency list  
returned by artifact:dependencies is empty.

I've traced through it and here is some more information:
DefaultArtifactCollector applies the filter using  
ResolutionNode.filterTrail. This iterates over the (dependency)  
node trail and applies the specified filter to each dependency in  
turn. If all dependencies are of the same type and the type  
matches the one specified in the filter, no problems. However,  
I've got a dependency that is a war archive and that in turn has  
some jar dependencies. If type is set to jar, filter fails when  
testing the first dependency in the trail - the war in this case  
and never gets to the jar. The result is that whatever the value  
of the type attribute, the dependency list always ends up empty  
for trails that contain dependencies of different types.


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





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

Re: We're near the release of 1.0 final

[Jason van Zyl]

On 28 Mar 07, at 9:03 AM 28 Mar 07, Brett Porter wrote:



On 28/03/2007, at 10:35 PM, Jason van Zyl wrote:



No, please don't fragment even more our documentation situation.  
We have the stuff in SVN, Confluence users spaces and developer  
works spaces. The autoexport could easily be setup with the space  
we have if it isn't already.


This documentation is already in its own space, so it's low impact.  
I believe it is not currently editable by users, and only a couple  
of pages. This does no harm to the current situation, and gives us  
the opportunity to try it out.


Reasons I believe cwiki is a better choice:
- autoexport is already configured. No work to do.
- We have a greater level of access than we do at codehaus.
- No banner ads.
- It's back on the apache.org domain.

I don't see any downside...



Other then the severe one one of fragmenting our documentation. Do  
what you like.


Jason.


Cheers,
Brett

Re: Adding default OSGi information to JARs

[Jason van Zyl]

On 28 Mar 07, at 9:15 AM 28 Mar 07, Damien Lecan wrote:


> How this will be done ?
At first by putting an innocuous plugin in the lifecycle, or in 2.1
with extensions in Plexus it will be an extension to the JAR plugin
that populates manifest information.


It would be great if that could be available in 2.0.x version of
Maven. We are too far from 2.1 version.



Changing the lifecycle is not technically hard but it's still a  
change at a very fundamental level. I don't see this going into 2.0.x.



> Will it be active by default ?
If we decide that it's non-invasive and doesn't significantly
increase the time of anyone's builds then I see so harm.


Ok I understand, but you didn't answer my (not clear) question : if
OSGi packaging is fast enough, will OSGi manifest entries be
transparently added to every maven-build jars ?


Yes, they would be transparently added provided it is entirely non- 
invasive and the performance impact is slight.




Or will it be an OSGi developer option, that will never be known and
used by other common people ?


Commons users will never see it. We're not pushing OSGi  
configurations in people's faces.


Jason.



Thanks

Damien

-
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: Adding default OSGi information to JARs

[Kaloyan Enimanev]

Hi Milos
I was just expressing an opinion :)
I'm not part of the Maven team.

best regards,
 Kaloyan


On 3/28/07, Milos Kleint <[EMAIL PROTECTED]> wrote:

if I understood correctly, OSGI bundles should have a special
packaging like ear/wars do and define it's lifecycle to include the
OSGI stuff in the resulting binary

Milos

On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:
> > > Ok I understand, but you didn't answer my (not clear) question : if
> > > OSGi packaging is fast enough, will OSGi manifest entries be
> > > transparently added to every maven-build jars ?
> > >
> > > Or will it be an OSGi developer option, that will never be known and
> > > used by other common people ?
> >
> > IMHO this should depend on the type of the artifact i.e. the OSGI
> > bundles should be recognizable as such in the way we recognize EJB's
> > or WAR files.
>
> EJB jar files can be OSGI bundles too ! :)
> See www.easybeans.org project
>
> But you're right, for WAR and EAR files, OSGi bundling has not been
> explored yet and should be enriched with OSGi information.
>
> Damien
>
> -
> 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: Adding default OSGi information to JARs

[Milos Kleint]

if I understood correctly, OSGI bundles should have a special
packaging like ear/wars do and define it's lifecycle to include the
OSGI stuff in the resulting binary

Milos

On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:

> > Ok I understand, but you didn't answer my (not clear) question : if
> > OSGi packaging is fast enough, will OSGi manifest entries be
> > transparently added to every maven-build jars ?
> >
> > Or will it be an OSGi developer option, that will never be known and
> > used by other common people ?
>
> IMHO this should depend on the type of the artifact i.e. the OSGI
> bundles should be recognizable as such in the way we recognize EJB's
> or WAR files.

EJB jar files can be OSGI bundles too ! :)
See www.easybeans.org project

But you're right, for WAR and EAR files, OSGi bundling has not been
explored yet and should be enriched with OSGi information.

Damien

-
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: Adding default OSGi information to JARs

[Damien Lecan]

> Ok I understand, but you didn't answer my (not clear) question : if
> OSGi packaging is fast enough, will OSGi manifest entries be
> transparently added to every maven-build jars ?
>
> Or will it be an OSGi developer option, that will never be known and
> used by other common people ?

IMHO this should depend on the type of the artifact i.e. the OSGI
bundles should be recognizable as such in the way we recognize EJB's
or WAR files.


EJB jar files can be OSGI bundles too ! :)
See www.easybeans.org project

But you're right, for WAR and EAR files, OSGi bundling has not been
explored yet and should be enriched with OSGi information.

Damien

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

Re: [m2] findbugs xml parser

[Garvin LeClaire]

Which version of the Findbugs plugin are you using?
Are you able to send me the findbugs.xml file?




--
Regards,


Garvin LeClaire
[EMAIL PROTECTED]




On 3/28/07, dvicente <[EMAIL PROTECTED]> wrote:



Hi,

for my dashboard-maven-plugin, i want to parse the xml result file of
findbugs.

Does anyone know if exist a parser in the API to retreive all objects
structure without to parse the file as a simple xml file ?

the findbugs-maven-plugin generate xml file in wrong format .

it generates messages as "Error analyzing public void " where init
is
a method and do a parseException.

Does anyone know to correct that ?
--
View this message in context:
http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9710627
Sent from the Maven Developers mailing list archive at Nabble.com.


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

Re: Adding default OSGi information to JARs

[Kaloyan Enimanev]

On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:

> > How this will be done ?
> At first by putting an innocuous plugin in the lifecycle, or in 2.1
> with extensions in Plexus it will be an extension to the JAR plugin
> that populates manifest information.

It would be great if that could be available in 2.0.x version of
Maven. We are too far from 2.1 version.

> > Will it be active by default ?
> If we decide that it's non-invasive and doesn't significantly
> increase the time of anyone's builds then I see so harm.

Ok I understand, but you didn't answer my (not clear) question : if
OSGi packaging is fast enough, will OSGi manifest entries be
transparently added to every maven-build jars ?

Or will it be an OSGi developer option, that will never be known and
used by other common people ?


IMHO this should depend on the type of the artifact i.e. the OSGI
bundles should be recognizable as such in the way we recognize EJB's
or WAR files.

This will provide a clear way to determine whether an artifact needs
OSGI specific headers or not.

best regards,
 Kaloyan



Thanks

Damien

-
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: Adding default OSGi information to JARs

[Damien Lecan]

> How this will be done ?
At first by putting an innocuous plugin in the lifecycle, or in 2.1
with extensions in Plexus it will be an extension to the JAR plugin
that populates manifest information.


It would be great if that could be available in 2.0.x version of
Maven. We are too far from 2.1 version.


> Will it be active by default ?
If we decide that it's non-invasive and doesn't significantly
increase the time of anyone's builds then I see so harm.


Ok I understand, but you didn't answer my (not clear) question : if
OSGi packaging is fast enough, will OSGi manifest entries be
transparently added to every maven-build jars ?

Or will it be an OSGi developer option, that will never be known and
used by other common people ?

Thanks

Damien

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

Re: We're near the release of 1.0 final

[Emmanuel Venisse]

Brett Porter a écrit :


On 28/03/2007, at 10:35 PM, Jason van Zyl wrote:



No, please don't fragment even more our documentation situation. We 
have the stuff in SVN, Confluence users spaces and developer works 
spaces. The autoexport could easily be setup with the space we have if 
it isn't already.


This documentation is already in its own space, so it's low impact. I 
believe it is not currently editable by users, and only a couple of 
pages. This does no harm to the current situation, and gives us the 
opportunity to try it out.


We have actually only one page in the codehaus wiki (the provider matrix).



Reasons I believe cwiki is a better choice:
- autoexport is already configured. No work to do.
- We have a greater level of access than we do at codehaus.
- No banner ads.
- It's back on the apache.org domain.

I don't see any downside...


We'd can use the codehaus wiki for our dev/design pages and for users pages 
we'd can use the cwiki with the autoexport and the maven css to include the 
content in our site.
I think it would be good to do it for our other products, so we'd can create 
easily cookbooks, but this ML isn't the place to discuss it ;)

Emmanuel

New JIRA Project for Ant Tasks

[Jason van Zyl]

Hi,

I'm planning on releasing the Ant Tasks after the release of 2.0.6 so  
if you have any issues please look here:


http://jira.codehaus.org/browse/MANTTASKS

I've moved all the issues from MNG to MANTTASKS and if there's  
anything folks really want I will schedule a couple things for  
alpha-1 of the Ant tasks. They are working with the 2.0.6 snapshot so  
I think it's just good to get them out but I'll fix what minor issues  
I can release staging a a release.


Thanks,

Jason.



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

Re: [jira] Moved: (MANTTASKS-41) type attribute of artifact:dependencies doesn't work for indirect dependencies

[Brett Porter]

Jason,

Can you set up the released versions for these before moving more  
issues so that affects versions, etc are retained? I only see 1.0- 
alpha-1 in there at the moment, and it doesn't make much sense to go  
backwards.


I've adjusted the project configuration to be standard maven style  
(workflow, creation screen).


We should also move the old issues out of MNG so they remain together  
and remove the component.


Let me know if I can help with any of these.

Cheers,
Brett

On 28/03/2007, at 11:01 PM, Jason van Zyl (JIRA) wrote:



 [ http://jira.codehaus.org/browse/MANTTASKS-41? 
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]


Jason van Zyl moved MNG-1542 to MANTTASKS-41:
-

Complexity:   (was: Intermediate)
   Key: MANTTASKS-41  (was: MNG-1542)
   Project: Maven 2.x Ant Tasks  (was: Maven 2)
  Workflow: jira  (was: Maven New)

type attribute of artifact:dependencies doesn't work for indirect  
dependencies
- 
-


Key: MANTTASKS-41
URL: http://jira.codehaus.org/browse/MANTTASKS-41
Project: Maven 2.x Ant Tasks
 Issue Type: Sub-task
 Components: Ant tasks
   Affects Versions: 2.0
   Reporter: Tomislav Bodor
Fix For: 2.1.x

Attachments: build.xml, pom.xml


It appears that the type filter doesn't work properly with  
indirect dependencies. It doesn't look like an issue with the  
TypeArtifactFilter itself, but somewhere deeper. However, it's  
related to this feature, so here it is...
The problem manifests with transitive dependencies that are of  
different type, e.g. a war artefact depends on a jar library.  
Whatever the type in that case (jar or war), the dependency list  
returned by artifact:dependencies is empty.

I've traced through it and here is some more information:
DefaultArtifactCollector applies the filter using  
ResolutionNode.filterTrail. This iterates over the (dependency)  
node trail and applies the specified filter to each dependency in  
turn. If all dependencies are of the same type and the type  
matches the one specified in the filter, no problems. However,  
I've got a dependency that is a war archive and that in turn has  
some jar dependencies. If type is set to jar, filter fails when  
testing the first dependency in the trail - the war in this case  
and never gets to the jar. The result is that whatever the value  
of the type attribute, the dependency list always ends up empty  
for trails that contain dependencies of different types.


--
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: We're near the release of 1.0 final

[Brett Porter]

On 28/03/2007, at 10:35 PM, Jason van Zyl wrote:



No, please don't fragment even more our documentation situation. We  
have the stuff in SVN, Confluence users spaces and developer works  
spaces. The autoexport could easily be setup with the space we have  
if it isn't already.


This documentation is already in its own space, so it's low impact. I  
believe it is not currently editable by users, and only a couple of  
pages. This does no harm to the current situation, and gives us the  
opportunity to try it out.


Reasons I believe cwiki is a better choice:
- autoexport is already configured. No work to do.
- We have a greater level of access than we do at codehaus.
- No banner ads.
- It's back on the apache.org domain.

I don't see any downside...

Cheers,
Brett

Re: We're near the release of 1.0 final

[Jason van Zyl]

On 27 Mar 07, at 9:50 PM 27 Mar 07, Brett Porter wrote:



On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote:

- should we move the SCM space to cwiki since it can be  
autoexported? Then we can put the provider matrix and the provider  
details pages together and link them in to the site as static pages




No, please don't fragment even more our documentation situation. We  
have the stuff in SVN, Confluence users spaces and developer works  
spaces. The autoexport could easily be setup with the space we have  
if it isn't already.


Jason.

Re: Adding default OSGi information to JARs

[Jason van Zyl]

On 28 Mar 07, at 4:02 AM 28 Mar 07, Damien Lecan wrote:


Hello,


[...]
 it is entirely non-invasive then I
think it would be fine to add to the default lifecycle.


How this will be done ?


At first by putting an innocuous plugin in the lifecycle, or in 2.1  
with extensions in Plexus it will be an extension to the JAR plugin  
that populates manifest information.



Does "bundle" packaging will become official, or will it supercede
default jar packaging ?


Never.


Will it be active by default ?



If we decide that it's non-invasive and doesn't significantly  
increase the time of anyone's builds then I see so harm.


Jason.


Thank you for this great job !

Damien Lecan

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





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

[m2] findbugs xml parser

[dvicente]

Hi,

for my dashboard-maven-plugin, i want to parse the xml result file of
findbugs.

Does anyone know if exist a parser in the API to retreive all objects
structure without to parse the file as a simple xml file ?

the findbugs-maven-plugin generate xml file in wrong format .

it generates messages as "Error analyzing public void " where init is
a method and do a parseException.

Does anyone know to correct that ?
-- 
View this message in context: 
http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9710627
Sent from the Maven Developers mailing list archive at Nabble.com.


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

NullPointerException at org.apache.maven.plugin.descriptor.PluginDescriptor.getMojo(PluginDes

[neo.nirav]

Hi all,

I just searched the topic and found that if we put our plugin in
org.apache.maven.plugins,  = groupdID, the plugin should run and as per the
previous discussion it worked for the topic starter BUT, i tried the same
and still getting the error!! :(

Any solution please..

C:\mp\test\sample-plugin>mvn hello:sayhi
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'hello'.
[INFO] artifact org.apache.maven.plugins:maven-hello-plugin: checking for
update
s from central
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] null
[INFO]

[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.descriptor.PluginDescriptor.getMojo(PluginDes
criptor.java:262)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor
(DefaultLifecycleExecutor.java:1529)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListBy
AggregationNeeds(DefaultLifecycleExecutor.java:386)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:138)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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: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)

-- 
View this message in context: 
http://www.nabble.com/NullPointerException-at-org.apache.maven.plugin.descriptor.PluginDescriptor.getMojo%28PluginDes-tf3478847s177.html#a9708851
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: We're near the release of 1.0 final

[Emmanuel Venisse]

Brett Porter a écrit :

I think it's definitely time for another beta ASAP.

For 1.0, I'd still like to review (if not include) the following JIRAs.

High priority:
- SCM-17: I think the test structure needs some review, and we need to 
ensure all unit tests run fast and without the software installed. The 
TCK should be used to execute as integration tests when the software is 
installed. I think this sets us in a good position for a more stable API 
and the ability to have quality providers (per the other discussion on 
the list)


agreed


- SCM-156, 157, 158: TCK tests for various providers. Ties in to the above.


we can't implement TCK tests for all providers without access to all SCM tools.
And it seems that contributors on providers without TCK implementation doesn't want or don't find time to do it, maybe it will be different when the TCK will be documented (I don't know yet how to 
document it)


- SCM-18: it seems some commands are not currently implemented in some 
providers?


Yes. I don't think the implementation of all commands is a requirement for a 
release.
1. If we don't allow to release without all commands, I'm not sure contributor 
will contribute more and they probably keep their provider private with what 
they need.
2. it isn't possible to implement all commands in all providers because some 
command aren't supported by some SCM tool
3. without contribution or an access to a SCM tool, we can't implement missing 
commands



Note: I'm happy to cut down the number of providers for the 1.0 release 
(and version the others as beta or have a larger sandbox) if that's what 
it takes. That would be more around the model of separated releases though.


Medium priority (because they might change the API it could be better to 
do before 1.0):

- SCM-21: separate revision and tag handling


if we want it before 1.0, it would be good to implement it in a beta, so it 
will can be tested before the 1.0 release
I'm not sure we'll can do it easily in all providers without contribution. 
Probably possible if we keep in API the current behaviour.


- SCM-133: API clean up around repositories


same comment for a new beta, but I'm thinking to a big API change for Maven-SCM 
2 that will simplify provider implementation and will allow specific SCM 
options (I'll write a design doc about that later)



Low priority:
- SCM-243: 'X' is treated as unknown in SVN. Seems like a simple fix, 
might be worth doing.


Yes it's a simple fix I can include in the release. I'll like to parse svn 
properties changes too, but probably later.



I'll also review the docs.

I think it's critical we have the testing in order before doing the 1.0 
release - wdyt?


I'll move all IT tests under a src/it directory in each provider and try to 
document the TCK ASAP.

Emmanuel



- Brett

On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote:


Hi,

Now, we have only one issue to fix and all issues assigned to 1.0 will 
be fixed :)


I added two development guide in the site, it would be cool if you can 
look at it.


Emmanuel

Re: Adding default OSGi information to JARs

[Damien Lecan]

Hello,


[...]
 it is entirely non-invasive then I
think it would be fine to add to the default lifecycle.


How this will be done ?
Does "bundle" packaging will become official, or will it supercede
default jar packaging ?
Will it be active by default ?

Thank you for this great job !

Damien Lecan

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