On Jan 20, 2014, at 12:32 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
If we are going wholesale dumping issues (and I am not against that), I
have a more radical suggestion... let's just move core to the ASF JIRA...
with next to no issues needing migration it would be easy
Works for me to just start over on the ASF JIRA. There are a couple issues I'd
move but we can migrate a issues easily. What can't continue is the complete,
incomprehensible mess that is there now.
On Jan 20, 2014, at 12:32 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
If we
+1 with a jira cleanup (but documented and announced to users to let them
understand what we do and why)
+1 to move to ASF
On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote:
Works for me to just start over on the ASF JIRA. There are a couple issues
I'd move but we can
+1 cleanup is a really good idea!
On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote:
+1 with a jira cleanup (but documented and announced to users to let them
understand what we do and why)
+1 to move to ASF
On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja
+1 on clean up if we communicate this (and explain why).
0 on move
/Anders
On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote:
+1 cleanup is a really good idea!
On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote:
+1 with a jira cleanup
+1 here.
On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net wrote:
+1 on clean up if we communicate this (and explain why).
0 on move
/Anders
On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote:
+1 cleanup is a really good idea!
On 20.01.2014, at 18
/Anders
On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote:
+1 cleanup is a really good idea!
On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote:
+1 with a jira cleanup (but documented and announced to users to let them
understand what we do
GitHub user ebourg opened a pull request:
https://github.com/apache/maven-wagon/pull/8
Code cleanup
Here is a patch performing minor code improvements (foreach loops,
generics, unused imports, StringBuilders, etc)
You can merge this pull request into a Git repository by running
Github user ebourg closed the pull request at:
https://github.com/apache/maven-wagon/pull/8
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
On 15 July 2013 23:26, aherit...@apache.org wrote:
Code cleanup - Maven requires Java 5+ : Remove unnecessary boxing
Not sure that's a good idea.
I've found quite a few bugs related to boxing in other projects.
For example, auto-unboxing a field that can sometimes be null may
cause
On 15 July 2013 23:26, aherit...@apache.org wrote:
Code cleanup - Maven requires Java 5+ : Replace for and while loops by for
each
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/d92746dc
Tree: http://git-wip
+1 for me to accept only : *-SNAPSHOT.
Included 1-SNAPSHOT (our parent poms use this forms), 1.0-SNAPSHOT (a
lot of people/company use the a.b qualifier).
IMHO we must emit a warning/deprecation in 3.0.x for version with only
SNAPSHOT (and fail in 3.1.x).
2010/12/28 Benjamin Bentmann
--mobile
On Dec 28, 2010, at 6:50 PM, Jason van Zyl ja...@maven.org wrote:
On Dec 28, 2010, at 6:06 PM, Benjamin Bentmann wrote:
Brian E. Fox wrote:
-1 to a, +1 to b
Just to be clear, I meant a) AND b), not either or. a) is concerned about
the actual version interpretation, b) about
Brett Porter wrote:
I think the original reason the logic is how it is was because just SNAPSHOT
(with no leading version) was valid, but that behaviour has long been (unofficially)
deprecated.
Given this style of versioning is apparently in use and I personally see
nothing wrong with
On Dec 28, 2010, at 10:02 AM, Benjamin Bentmann wrote:
Brett Porter wrote:
I think the original reason the logic is how it is was because just
SNAPSHOT (with no leading version) was valid, but that behaviour has long
been (unofficially) deprecated.
Given this style of versioning is
-1 to a, +1 to b
--Brian (mobile)
On Dec 28, 2010, at 1:20 PM, Jason van Zyl ja...@maven.org wrote:
On Dec 28, 2010, at 10:02 AM, Benjamin Bentmann wrote:
Brett Porter wrote:
I think the original reason the logic is how it is was because just
SNAPSHOT (with no leading version) was
Brian E. Fox wrote:
-1 to a, +1 to b
Just to be clear, I meant a) AND b), not either or. a) is concerned
about the actual version interpretation, b) about guiding the user into
the desired direction for future projects.
In light of this, I'm not sure what your -1 to a means.
Benjamin
On Dec 28, 2010, at 6:06 PM, Benjamin Bentmann wrote:
Brian E. Fox wrote:
-1 to a, +1 to b
Just to be clear, I meant a) AND b), not either or. a) is concerned about the
actual version interpretation, b) about guiding the user into the desired
direction for future projects.
In light
But then how do you handle releases of the referencing projects? A clean
release must never reference any snapshot, I don't see how you do it.
Le 16 déc. 2010 00:33, Jörg Hohwiller jo...@j-hohwiller.de a écrit :
Hi there,
FYI:
I use SNAPSHOT as version for internal artifacts
Hi Baptiste,
Baptiste MATHUS wrote:
But then how do you handle releases of the referencing projects? A clean
release must never reference any snapshot, I don't see how you do it.
Hmm, Jörg Hohwiller pointed out that *he* does not release those artifacts.
So is this a question to my reply in
2010/12/16 Jörg Schaible joerg.schai...@scalaris.com
Hi Baptiste,
Baptiste MATHUS wrote:
But then how do you handle releases of the referencing projects? A clean
release must never reference any snapshot, I don't see how you do it.
Hmm, Jörg Hohwiller pointed out that *he* does not
Hi Baptiste,
Baptiste MATHUS wrote:
2010/12/16 Jörg Schaible joerg.schai...@scalaris.com
Hi Baptiste,
Baptiste MATHUS wrote:
But then how do you handle releases of the referencing projects? A
clean release must never reference any snapshot, I don't see how you do
it.
Hmm, Jörg
Hi there,
FYI:
I use SNAPSHOT as version for internal artifacts (site-configurations with
checkstyle, etc.) to denote that they will never get released.
However in such case one typically does not need real SNAPSHOT support by
maven. I could also name the version notversioned or 0.0.
Regards
Or, 1-SNAPSHOT.
Or, DO-NOT-RELEASE-1-SNAPSHOT
On Wed, Dec 15, 2010 at 6:33 PM, Jörg Hohwiller jo...@j-hohwiller.de wrote:
Hi there,
FYI:
I use SNAPSHOT as version for internal artifacts (site-configurations with
checkstyle, etc.) to denote that they will never get released.
However in
On 13/12/2010, at 10:41 PM, Benjamin Bentmann wrote:
Brett Porter wrote:
[...] SNAPSHOT (with no leading version) was valid, but that behaviour has
long been (unofficially) deprecated.
Do you have some more pointers for this deprecation handy?
No - that's what I meant by unofficial :)
Hi Benjamin,
Benjamin Bentmann wrote:
Hi,
as part of MNG-4893 [0] an inconsistency in the way a version string is
treated as a snapshot or release was detected. In short, the issue is
about what suffix exactly marks a snapshot version.
The current intention is to revise the logic such
2010/12/13 Jörg Schaible joerg.schai...@scalaris.com
Hi Benjamin,
Benjamin Bentmann wrote:
Hi,
as part of MNG-4893 [0] an inconsistency in the way a version string is
treated as a snapshot or release was detected. In short, the issue is
about what suffix exactly marks a snapshot
Hi Baptise,
Baptiste MATHUS wrote:
2010/12/13 Jörg Schaible joerg.schai...@scalaris.com
Hi Benjamin,
Benjamin Bentmann wrote:
Hi,
as part of MNG-4893 [0] an inconsistency in the way a version string is
treated as a snapshot or release was detected. In short, the issue is
about
If x-SNAPSHOT.release() = x then SNAPSHOT.release()= npe or divide by
zero, take your pick :)
I always made sure to point out this anti-pattern during all the maven
training classes I did.
--mobile
On Dec 13, 2010, at 6:42 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Brett Porter
I think I've seen some projects, although I don't recall where, that use
.SNAPSHOT because then you get legal osgi bundle versions in require-bundle
instructions in the maven-bundle-plugin. Presumably this could be fixed in the
maven-bundle-plugin since it already converts -SNAPSHOT to
I can actually see what's going on in JIRA using JIRAClient. I haven't found
Mylyn very effective with the number of issues we have but JIRAClient is pretty
effective. It downloads the data locally and then you can do all sorts of cool
queries to help find stuff.
Makes some of the JIRA cleanup
I have proposed in the original thread a solution, based on multiple
index files, which index files would represent the output of CAs. If I
configure in my Maven settings file (by URL) which index file I want
to use, my Maven should be blind to any other artifacts on the repo.
Allowing AND
Wayne, Who paid Linus to create version 1.0 of the Linux Kernel?
If somebody can create a Maven repo crawler as a hobby project, then
somebody will.
The first Cert List will probably be just the result of some simple
tests, not much.
But many will follow. We will have to protect somehow our
On Thu, Oct 1, 2009 at 2:24 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Wayne, Who paid Linus to create version 1.0 of the Linux Kernel?
If somebody can create a Maven repo crawler as a hobby project, then
somebody will.
The Nexus Indexer already runs on Central, directly on the machine.
1) defined rules for what an acceptable artifact is
2) gating central with those rules
Any time when I referred to
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
as a requirement, I always had a bad feeling.
Why? Requirement is what you can verify against, but this mini
Ok, I did a poor job of expressing what I was getting at.
On 25/09/2009, at 2:02 PM, Jason van Zyl wrote:
What's matters is improvement of the process going forward.
Agreed, I see that as a pre-requisite.
As people move forward with improved submissions from projects then
the older
Here, in my view are some of the issues we face going forwards:
1. There is sufficient stuff deployed to central with poor quality poms
which do not meet our own criteria for artifact hosting on central, that
central risks being considered unreliable. Some of these artifacts arose
I think it is TOTAL important we keep the contract:
*** This is a long standing rule that we do not remove or change the
contents of central ***
Therefore a way out could be to start making deprecated tags in the
directories.
Then we could come up with a ***
+1 to adding deprecation metadata.
-1 to having a plugin... the deprecation warnings should come from
maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
Also if we are adding deprecation metadata, there are a number of
other little bits of metadata that should be added, e.g.
Hi all,
I also like the idea about deprecating artifacts, or whole directory structure.
A step forward would be to create a maven-dev-approved repositories or
artifacts.
Imagine you are using an outside repository that is really messed up
(or worse - anyone can put anything any time).
What maven
.
There is no big bang cleanup that makes it all better. That is just a
pipe dream. We just have to incrementally and diligently clean up what
we have. Maven Central is a great resource and it needs some TLC but
not cleansing.
Imagine you are using an outside repository that is really
Moving over to dev...
So here's a thought - why don't we create a new central repository?
- a new repository with strict acceptance rules regarding POMs,
signatures, ownership, etc.
- if there's a new metadata format needed (recently discussed), this
would use it
- validated artifacts could
On 2009-09-24, at 8:37 PM, Brett Porter wrote:
Moving over to dev...
So here's a thought - why don't we create a new central repository?
- a new repository with strict acceptance rules regarding POMs,
signatures, ownership, etc.
- if there's a new metadata format needed (recently
This has already been done once in history, between M1 and M2 and look
how we still have that mess to deal with all the time. Doing this
again serves no one well, making sure new data coming in is clean is
more productive for everyone. Who would _want_ to deploy their stuff
to the old repo? No
Hello, Benjamin,
Please feel free to suppress those things.
I got in a hurry at work since the attempt to release.
I will retry early september, as i think i will have some spare time.
If anyone has courage to do the release, meanwhile...
Th actual code has my +1
Regards,
Raphaël
What's it waiting for?
2009/7/21 Raphaël Piéroni raphaelpier...@gmail.com:
Hello, Benjamin,
Please feel free to suppress those things.
I got in a hurry at work since the attempt to release.
I will retry early september, as i think i will have some spare time.
If anyone has courage to do
Hi,
On people.a.o I noticed some docs that likely can be deleted:
drwxrwxr-x 11 rafale maven 1536 Apr 21 17:24
maven-archetype-plugin-2.0-alpha-5
drwxr-xr-x 10 aheritier maven 1536 Sep 9 2008
maven-eclipse-plugin-2.6-SNAPSHOT
drwxr-xr-x 10 aheritier maven 1536 Apr 15 23:18
Hi,
Thx for the reminder :-)
I removed maven-eclipse-plugin-2.6-SNAPSHOT
and maven-eclipse-plugin-2.7-SNAPSHOT
cheers
Arnaud
On Sun, Jul 19, 2009 at 11:54 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Hi,
On people.a.o I noticed some docs that likely can be deleted:
sync to central for groupId com.extjs occured just during a content update.I
now have a
gxt-1.1.jar.fileparthttp://repo1.maven.org/maven2/com/extjs/gxt/1.1/gxt-1.1.jar.filepartfile
in
http://repo1.maven.org/maven2/com/extjs/gxt/1.1/
Can someone please delete this 1.1 folder, so that it gets a
done
On 19/09/2008, at 9:08 PM, nicolas de loof wrote:
sync to central for groupId com.extjs occured just during a content
update.I
now have a gxt-1.1.jar.fileparthttp://repo1.maven.org/maven2/com/extjs/gxt/1.1/gxt-1.1.jar.filepart
file
in
http://repo1.maven.org/maven2/com/extjs/gxt/1.1/
sync to central for groupId com.extjs occured just during a content update.I
now have a
gxt-1.1.jar.fileparthttp://repo1.maven.org/maven2/com/extjs/gxt/1.1/gxt-1.1.jar.filepartfile
in
http://repo1.maven.org/maven2/com/extjs/gxt/1.1/
Can someone please delete this 1.1 folder, so that it
it will need to resync... the jar isn't there either.
- Brett
On 19/09/2008, at 9:52 PM, Henri Gomez wrote:
sync to central for groupId com.extjs occured just during a content
update.I
now have a gxt-1.1.jar.fileparthttp://repo1.maven.org/maven2/com/extjs/gxt/1.1/gxt-1.1.jar.filepart
file
Brett, could you please fully cleanup the folder so that I can double check
the orginial folder ?
2008/9/19 Brett Porter [EMAIL PROTECTED]
it will need to resync... the jar isn't there either.
- Brett
On 19/09/2008, at 9:52 PM, Henri Gomez wrote:
sync to central for groupId com.extjs
Not a big deal, but I usually don't delete real artifacts that are
already there. These all have checksums to check against. Shouldn't
the next sync just pick up the missing files?
- Brett
On 19/09/2008, at 10:08 PM, nicolas de loof wrote:
Brett, could you please fully cleanup the folder
the next sync
just pick up the missing files?
- Brett
On 19/09/2008, at 10:08 PM, nicolas de loof wrote:
Brett, could you please fully cleanup the folder so that I can double
check
the orginial folder ?
2008/9/19 Brett Porter [EMAIL PROTECTED]
it will need to resync... the jar isn't
PROTECTED]
Not a big deal, but I usually don't delete real artifacts that are
already
there. These all have checksums to check against. Shouldn't the
next sync
just pick up the missing files?
- Brett
On 19/09/2008, at 10:08 PM, nicolas de loof wrote:
Brett, could you please fully cleanup
On 12/19/06, Brett Porter [EMAIL PROTECTED] wrote:
Hen:
MRM-207 Major POM error when indexing an m1 repositoryHenri
Yandell
MRM-208 Major Javadoc error while indexing m1 repository Henri
Yandell
Not sure when I'll retest them; but as it's based on test data on
Hi All,
This message is for all of you using the Continuum release integration
branch located here:
https://svn.apache.org/repos/asf/maven/continuum/branches/release-integration
Please update your local working copy as soon as you get this as I have
cleaned up the directory structure for
Hmm... should I be working in this branch instead of the trunk?
- Brill Pappin
Jeremy Whitlock wrote:
Hi All,
This message is for all of you using the Continuum release integration
branch located here:
https://svn.apache.org/repos/asf/maven/continuum/branches/release-integration
Please
On 31 Aug 06, at 9:25 PM 31 Aug 06, Brill Pappin wrote:
Hmm... should I be working in this branch instead of the trunk?
No, they are merging trunk into that branch as that branch will all
go back to trunk shortly.
- Brill Pappin
Jeremy Whitlock wrote:
Hi All,
This message is for
[ http://jira.codehaus.org/browse/CONTINUUM-507?page=all ]
John Casey reopened CONTINUUM-507:
--
detect and repair svn problems by running svn cleanup
-
Key: CONTINUUM-507
URL
[ http://jira.codehaus.org/browse/CONTINUUM-507?page=all ]
John Casey closed CONTINUUM-507:
Resolution: Fixed
Fix Version: (was: 1.1-alpha-1)
1.0.3
detect and repair svn problems by running svn cleanup
cleanup
-
Key: CONTINUUM-507
URL: http://jira.codehaus.org/browse/CONTINUUM-507
Project: Continuum
Type: Bug
Components: Core system
Reporter: Brett Porter
Fix For: 1.1-alpha-1
builds fail when
[ http://jira.codehaus.org/browse/SCM-118?page=all ]
Emmanuel Venisse closed SCM-118:
Assign To: Emmanuel Venisse
Resolution: Fixed
Fixed.
detect and repair svn problems by running svn cleanup
detect and repair svn problems by running svn cleanup
-
Key: SCM-118
URL: http://jira.codehaus.org/browse/SCM-118
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-svn
Versions: 1.0-beta-2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-415?page=all ]
Carlos Sanchez closed MAVENUPLOAD-415:
--
Assign To: Carlos Sanchez
Resolution: Fixed
Cleanup Findbugs related directories on ibiblio
[ http://jira.codehaus.org/browse/MNG-363?page=all ]
Brett Porter updated MNG-363:
-
Fix Version: (was: 2.0-beta-1)
2.0-beta-2
old code cleanup - cli, messages, etc
-
Key: MNG-363
be deleted, aren't the jar of the project?
Cleanup Findbugs related directories on ibiblio
---
Key: MAVENUPLOAD-415
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-415
Project: maven-upload-requests
Type: Task
Cleanup Findbugs related directories on ibiblio
---
Key: MAVENUPLOAD-415
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-415
Project: maven-upload-requests
Type: Task
Reporter: David Eric Pugh
There has been a bit
old code cleanup - cli, messages, etc
-
Key: MNG-363
URL: http://jira.codehaus.org/browse/MNG-363
Project: m2
Type: Task
Components: maven-core
Reporter: Brett Porter
Fix For: 2.0-beta-1
there are some lingering
Periodic cleanup of logs and builds
---
Key: MNG-346
URL: http://jira.codehaus.org/browse/MNG-346
Project: m2
Type: Task
Reporter: Brett Porter
the m2-build-logs and distributions from ci.sh are a bit out of control in
/home
: MPXDOC-107
Summary: code cleanup in DescribedDependency
Type: Improvement
Status: Open
Priority: Trivial
Original Estimate: 1 minute
Time Spent: Unknown
Remaining: 1 minute
Project: maven-xdoc-plugin
Versions:
1.7.1
Assignee: Jason van Zyl
:
-
Key: MPXDOC-107
Summary: code cleanup in DescribedDependency
Type: Improvement
Status: Closed
Priority: Trivial
Resolution: FIXED
Original Estimate: 1 minute
Time Spent: Unknown
Remaining: 1 minute
: MAVEN-1309
Summary: code cleanup in AbstractArtifact
Type: Improvement
Status: Closed
Priority: Trivial
Resolution: FIXED
Original Estimate: 1 minute
Time Spent: Unknown
Remaining: 1 minute
Project: maven
Components:
core
Fix Fors:
1.0
is an overview of the issue:
-
Key: MAVEN-1309
Summary: code cleanup in AbstractArtifact
Type: Improvement
Status: Unassigned
Priority: Trivial
Original Estimate: 1 minute
Time Spent: Unknown
Remaining
: MAVEN-1309
Summary: code cleanup in AbstractArtifact
Type: Improvement
Status: Unassigned
Priority: Trivial
Original Estimate: 1 minute
Time Spent: Unknown
Remaining: 1 minute
Project: maven
Components:
core
Versions:
1.0-rc3
:
-
Key: MAVEN-1309
Summary: code cleanup in AbstractArtifact
Type: Improvement
Status: Unassigned
Priority: Trivial
Original Estimate: 1 minute
Time Spent: Unknown
Remaining: 1 minute
Project: maven
Components:
core
Versions:
1.0-rc3
:
-
Key: MAVEN-1098
Summary: cleanup touchstone
Type: Task
Status: Closed
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven
Fix Fors:
1.0-rc3
Versions:
1.0-rc2
:
-
Key: MAVEN-1098
Summary: cleanup touchstone
Type: Task
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven
Fix Fors:
1.0
Jason van Zyl wrote:
On Thu, 2004-01-15 at 23:26, Ben Walding wrote:
id / groupId works in 1.0-rc1
groupId / artifactId doesn't
For the reactor to pick them up properly or in general?
In general.
And I know that the ordering of the elements matters. It is very very
dodgy.
I
+0 if and only if artifactId works with RC1. From memory, I don't think it
does.
- Brett
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 January 2004 6:41 PM
To: Maven Developers List
Subject: Plugin cleanup phase 1
Hi,
Does anyone object
-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 January 2004 6:41 PM
To: Maven Developers List
Subject: Plugin cleanup phase 1
Hi,
Does anyone object to flipping all the plugins over to using
groupId//artifactId/ instead of just id/ to promote the
the proper
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 January 2004 6:41 PM
To: Maven Developers List
Subject: Plugin cleanup phase 1
Hi,
Does anyone object to flipping all the plugins over to using
groupId//artifactId/ instead
PROTECTED]
Sent: Friday, 16 January 2004 1:33 AM
To: Maven Developers List
Subject: RE: Plugin cleanup phase 1
On Thu, 2004-01-15 at 16:48, Brett Porter wrote:
+0 if and only if artifactId works with RC1. From memory, I don't
+think it
does.
Ben, I think we cound that groupId/artifactId
]
Sent: Friday, 16 January 2004 1:33 AM
To: Maven Developers List
Subject: RE: Plugin cleanup phase 1
On Thu, 2004-01-15 at 16:48, Brett Porter wrote:
+0 if and only if artifactId works with RC1. From memory, I don't
+think it
does.
Ben, I think we cound that groupId
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, 16 January 2004 1:33 AM
To: Maven Developers List
Subject: RE: Plugin cleanup phase 1
On Thu, 2004-01-15 at 16:48, Brett Porter wrote:
+0 if and only if artifactId works with RC1. From memory, I don't
:
-
Key: MAVEN-1098
Summary: cleanup touchstone
Type: Task
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven
Fix Fors:
1.0-final
Versions:
1.0-rc2
Hi,
I have now removed all plugin components from the Maven core that have
no issues associated with them. So all plugin components that are now
there need to be dealt with. I notice for lots of plugins that have been
separated they still have issues associated with them in the core.
If you have
Howdy,
For almost all JIRA components in the main Maven project that were for
components have been removed and a new JIRA project for that specific
plugin has been created.
I took the liberty of deleting some dupes, or issues that have been
fixed that were so trivial that I saw no problem
If anyone is looking for something to do, moving anything not related to the
core out of touchstone and into the plugins as a plugin test project would
be great.
All I see is:
- sea
- deploy
Cheers,
Brett
--
Brett Porter
Team Leader, Core Systems
f2 network ~ everything essential
101 - 190 of 190 matches
Mail list logo
