Following up from a discussion on the user list. I think it's time to be
realistic about providing a healthy level of support for plugins here. I think
it makes more sense to reduce the foot print of plugins we say we support and
do those well as opposed to housing many plugin that just don't
This was a hack, and has now been replaced with Nexus staging here at Apache
(and most other forges). I believe this plugin can be archived now.
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
In much the same way we have a little sub-project for releasing I think it's
time to have one for the site generation. Take the maven-site-plugin and any
related plugins and move them into their own tree. What I'm trying to do here
is cull the set of plugins we have is to keep the ones that are
I agree.
Perhaps for some of them we could discuss to move them to mojo.codehaus.org to
let the community take the lead on them if we find some volunteers (I'm
thinking about the eclipse plugin for example).
Arnaud
On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote:
Following up from a
The built-in support from jetbrains has been excellent since version 7,
not much point in keeping this one around.
Kristian
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail:
On Nov 1, 2010, at 1:41 PM, Arnaud Héritier wrote:
I agree.
Perhaps for some of them we could discuss to move them to mojo.codehaus.org
to let the community take the lead on them if we find some volunteers (I'm
thinking about the eclipse plugin for example).
+1 to moving out the
On Nov 1, 2010, at 1:54 PM, Kristian Rosenvold wrote:
The built-in support from jetbrains has been excellent since version 7,
not much point in keeping this one around.
+1
Kristian
-
To unsubscribe, e-mail:
+1000
On 1 Nov 2010 12:54, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:
The built-in support from jetbrains has been excellent since version 7,
not much point in keeping this one around.
Kristian
-
To unsubscribe,
We can use http://svn.apache.org/repos/asf/maven/retired/ to start moving
plugins.
On Nov 1, 2010, at 1:54 PM, Kristian Rosenvold wrote:
The built-in support from jetbrains has been excellent since version 7,
not much point in keeping this one around.
Kristian
http://maven.apache.org/plugins/maven-one-plugin/
I think we're past its usefullness.
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
+1
--mobile
On Nov 1, 2010, at 8:40 AM, Jason van Zyl ja...@maven.org wrote:
This was a hack, and has now been replaced with Nexus staging here at Apache
(and most other forges). I believe this plugin can be archived now.
Thanks,
Jason
I started moving any of the ones discussed here:
http://svn.apache.org/repos/asf/maven/retired/
If anyone disagrees we can move them back but I think the ones suggest so far
are good candidates.
On Nov 1, 2010, at 1:37 PM, Jason van Zyl wrote:
Following up from a discussion on the user list.
+1.
I can be a volunteer for site stuff..
Question : what do we do with site plugin 2.x and 3.x branch ?
Personnally : I'd like to move only 3.x branch in this new project.
2010/11/1 Jason van Zyl ja...@maven.org:
In much the same way we have a little sub-project for releasing I think it's
http://maven.apache.org/plugins/maven-verifier-plugin/
Is that plugin (not to be confused with the shared maven-verifier
component) actually used?
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For
Your call, you're doing the work. Not sure we have any precedent, but I imagine
full support of the site plugin will require patches the 2.x version.
On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote:
+1.
I can be a volunteer for site stuff..
Question : what do we do with site plugin 2.x and
For the eclipse plugin, I think that just moving it to retired isn't a good
think because even if we are agree that this one is now really difficult to
maintain, this is always the preferred integration way with eclipse in many
corporate environments.
Thus we cannot just say to our community
+1
On Nov 1, 2010, at 1:41 PM, Jason van Zyl wrote:
In much the same way we have a little sub-project for releasing I think it's
time to have one for the site generation. Take the maven-site-plugin and any
related plugins and move them into their own tree. What I'm trying to do here
is
On Nov 1, 2010, at 3:04 PM, Arnaud Héritier wrote:
For the eclipse plugin, I think that just moving it to retired isn't a good
think because even if we are agree that this one is now really difficult to
maintain, this is always the preferred integration way with eclipse in many
corporate
+1
Sent from my iPhone
On 01 Nov 2010, at 13:54, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:
The built-in support from jetbrains has been excellent since version
7,
not much point in keeping this one around.
Kristian
Jason van Zyl wrote:
On Nov 1, 2010, at 3:04 PM, Arnaud Héritier wrote:
For the eclipse plugin, I think that just moving it to retired isn't a
good think because even if we are agree that this one is now really
difficult to maintain, this is always the preferred integration way with
Benjamin Bentmann wrote:
http://maven.apache.org/plugins/maven-verifier-plugin/
Is that plugin (not to be confused with the shared maven-verifier
component) actually used?
Yes. It's handly for verifying templated run scripts or stuff like that.
- Jörg
Go for it. I'm going to help retire them, after that it's fair game. So if you,
and the folks who might want to work on it, are cool with that then take it
over there.
My only concern is that we don't claim to support plugins that we have no real
intention of supporting. Having them in our SCM
+1 to consolidating the site stuff (under doxia?)
-0 to moving plugins that have non-site-specific capabilities (pmd, checkstyle,
etc.). Though these could be in a separate plugins tree for tool support, if
they aren't going to be held by the official projects.
On 01/11/2010, at 9:42 AM,
+1 to retire it
On 01/11/2010, at 9:00 AM, Benjamin Bentmann wrote:
http://maven.apache.org/plugins/maven-one-plugin/
I think we're past its usefullness.
Benjamin
-
To unsubscribe, e-mail:
+1 to retire it
On 01/11/2010, at 8:54 AM, Kristian Rosenvold wrote:
The built-in support from jetbrains has been excellent since version 7,
not much point in keeping this one around.
Kristian
-
To unsubscribe,
On 01/11/2010, at 1:29 PM, Jörg Schaible wrote:
Benjamin Bentmann wrote:
http://maven.apache.org/plugins/maven-verifier-plugin/
Is that plugin (not to be confused with the shared maven-verifier
component) actually used?
Yes. It's handly for verifying templated run scripts or stuff
Dennis committed to it just yesterday, so I think calling it unsupported is
premature.
On 01/11/2010, at 8:39 AM, Jason van Zyl wrote:
This was a hack, and has now been replaced with Nexus staging here at Apache
(and most other forges). I believe this plugin can be archived now.
Thanks,
Doesn't change the fact it's a hack, generally not useful and is generally not
going to get used.
Dennis, are you committed to supporting it?
If so, that's fine, but it's a dead end plugin as far as I'm concerned. Who's
going to use it when all the repository managers have some form of
On 01/11/2010, at 1:54 PM, Jason van Zyl wrote:
Doesn't change the fact it's a hack, generally not useful and is generally
not going to get used.
I don't disagree, but given it was just yesterday, I think Dennis should get to
finish what he's doing.
Dennis, are you committed to
On 01/11/2010, at 1:54 PM, Jason van Zyl wrote:
Doesn't change the fact it's a hack, generally not useful and is
generally not going to get used.
I don't disagree, but given it was just yesterday, I think Dennis should
get to finish what he's doing.
Dennis, are you committed to
On Nov 1, 2010, at 7:02 PM, Brett Porter wrote:
On 01/11/2010, at 1:54 PM, Jason van Zyl wrote:
Doesn't change the fact it's a hack, generally not useful and is generally
not going to get used.
I don't disagree, but given it was just yesterday, I think Dennis should get
to finish
Hi Jason
Doing some house cleaning among our plugins is a good thing, and I'm in
favor of retiring those that we feel that we cannot support.
However it is not OK for you to go changing things in Subversion less
than an hour after your proposal (which wasn't even labeled as one).
That is not the
Then -1 the commits.
We have a commit first, ask forgiveness second policy in maven last time I
checked
- Stephen
On 1 Nov 2010 21:05, Dennis Lundberg denn...@apache.org wrote:
Hi Jason
Doing some house cleaning among our plugins is a good thing, and I'm in
favor of retiring those that we
On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote:
Hi Jason
Doing some house cleaning among our plugins is a good thing, and I'm in
favor of retiring those that we feel that we cannot support.
However it is not OK for you to go changing things in Subversion less
than an hour after your
On 2010-11-01 18:54, Jason van Zyl wrote:
Doesn't change the fact it's a hack, generally not useful and is generally
not going to get used.
It actually is being used.
Dennis, are you committed to supporting it?
My plan is to close as many issues as I can and release a 1.0, to get
rid of one
+1 to retire it
On 2010-11-01 14:00, Benjamin Bentmann wrote:
http://maven.apache.org/plugins/maven-one-plugin/
I think we're past its usefullness.
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
+1 to retire it.
On 2010-11-01 14:44, Benjamin Bentmann wrote:
http://maven.apache.org/plugins/maven-verifier-plugin/
Is that plugin (not to be confused with the shared maven-verifier
component) actually used?
Benjamin
On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote:
Hi Jason
Doing some house cleaning among our plugins is a good thing, and I'm in
favor of retiring those that we feel that we cannot support.
However it is not OK for you to go changing things in Subversion less
than an hour after your
On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote:
On 2010-11-01 18:54, Jason van Zyl wrote:
Doesn't change the fact it's a hack, generally not useful and is generally
not going to get used.
It actually is being used.
Dennis, are you committed to supporting it?
My plan is to close
On 2010-11-01 22:14, Jason van Zyl wrote:
On Nov 1, 2010, at 10:04 PM, Dennis Lundberg wrote:
Hi Jason
Doing some house cleaning among our plugins is a good thing, and I'm in
favor of retiring those that we feel that we cannot support.
However it is not OK for you to go changing things
On Nov 1, 2010, at 6:37 PM, Brett Porter wrote:
+1 to consolidating the site stuff (under doxia?)
-0 to moving plugins that have non-site-specific capabilities (pmd,
checkstyle, etc.). Though these could be in a separate plugins tree for tool
support, if they aren't going to be held by
On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote:
+1.
I can be a volunteer for site stuff..
Question : what do we do with site plugin 2.x and 3.x branch ?
Personnally : I'd like to move only 3.x branch in this new project.
I would suggest these are the plugins that go as part of the
Hi
Given the discussions about retiring plugin I feel strongly that we need
to have a plan for doing so. There are bound to be differing opinions
about this, so see this as a starting point for discussions. When we get
to the point that we agree on the general process, I'll turn this
discussion
On 2010-11-01 22:10, Stephen Connolly wrote:
Then -1 the commits.
We have a commit first, ask forgiveness second policy in maven last time I
checked
So do you think that it's OK for someone to pull the rug from under your
feet, while you are working on something?
(as in my work on the Stage
Can you put this in Confluence. I think we should include the addition of
plugins as well ... as that's how we got here in the first place. New plugins,
if we ever add anymore, should require the same rigor going in.
On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote:
Hi
Given the
On Nov 1, 2010, at 10:37 PM, Dennis Lundberg wrote:
On 2010-11-01 22:10, Stephen Connolly wrote:
Then -1 the commits.
We have a commit first, ask forgiveness second policy in maven last time I
checked
So do you think that it's OK for someone to pull the rug from under your
feet, while
On 2010-11-01 13:41, Jason van Zyl wrote:
In much the same way we have a little sub-project for releasing I think it's
time to have one for the site generation. Take the maven-site-plugin and any
related plugins and move them into their own tree. What I'm trying to do here
is cull the set
On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote:
On 2010-11-01 13:41, Jason van Zyl wrote:
In much the same way we have a little sub-project for releasing I think it's
time to have one for the site generation. Take the maven-site-plugin and any
related plugins and move them into their
Jason van Zyl wrote:
I would suggest these are the plugins that go as part of the site generation:
[...]
maven-source-plugin
I think the maven-source-plugin is misclassified here, it doesn't have
any reporting code.
Benjamin
Yup. Cut/paste error.
On Nov 1, 2010, at 10:49 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
I would suggest these are the plugins that go as part of the site generation:
[...]
maven-source-plugin
I think the maven-source-plugin is misclassified here, it doesn't have any
reporting
I'm preparing the enforcer release and it needs the latest parent
changes, so I've cut a release:
Staged parent:
https://repository.apache.org/service/local/repositories/maven-008/content/org/apache/maven/maven-parent/17/maven-parent-17.pom
+1
Vote 72 hrs
On 2010-11-01 22:33, Jason van Zyl wrote:
On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote:
+1.
I can be a volunteer for site stuff..
Question : what do we do with site plugin 2.x and 3.x branch ?
Personnally : I'd like to move only 3.x branch in this new project.
I would suggest these
+1
On Nov 1, 2010, at 10:51 PM, Brian Fox wrote:
I'm preparing the enforcer release and it needs the latest parent
changes, so I've cut a release:
Staged parent:
https://repository.apache.org/service/local/repositories/maven-008/content/org/apache/maven/maven-parent/17/maven-parent-17.pom
On 2010-11-01 22:38, Jason van Zyl wrote:
Can you put this in Confluence.
Sure, I'll just wait for some feedback first, then I'll summarize it in
Confluence. Once the wrinkles are ironed out I'll move it to the site.
I think we should include the addition of plugins as well ... as that's how
Hi,
I agree in the fact to move unmaintened plugins but god, why are you
so quick one more time!
You asked Dennis to create a wiki page but you already retired the
plugins. Ok I know we could revert your changes but why send us an
email and move them 2 min after! We are a community Jason!
On Nov 1, 2010, at 10:57 PM, Dennis Lundberg wrote:
On 2010-11-01 22:38, Jason van Zyl wrote:
Can you put this in Confluence.
Sure, I'll just wait for some feedback first, then I'll summarize it in
Confluence. Once the wrinkles are ironed out I'll move it to the site.
I think we should
On 2010-11-01 22:48, Jason van Zyl wrote:
On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote:
On 2010-11-01 13:41, Jason van Zyl wrote:
In much the same way we have a little sub-project for releasing I think
it's time to have one for the site generation. Take the maven-site-plugin
and any
On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
Hi,
I agree in the fact to move unmaintened plugins but god, why are you
so quick one more time!
You asked Dennis to create a wiki page but you already retired the
plugins.
Yes, because I wouldn't write a wiki page, but if he wants some
On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote:
On 2010-11-01 22:48, Jason van Zyl wrote:
On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote:
On 2010-11-01 13:41, Jason van Zyl wrote:
In much the same way we have a little sub-project for releasing I think
it's time to have one for the
On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote:
On 2010-11-01 22:48, Jason van Zyl wrote:
On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote:
On 2010-11-01 13:41, Jason van Zyl wrote:
In much the same way we have a little sub-project for releasing I think
it's time to have one for
2010/11/1 Jason van Zyl ja...@maven.org:
On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
Hi,
I agree in the fact to move unmaintened plugins but god, why are you
so quick one more time!
You asked Dennis to create a wiki page but you already retired the
plugins.
Yes, because I
On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl ja...@maven.org wrote:
On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote:
On 2010-11-01 18:54, Jason van Zyl wrote:
Doesn't change the fact it's a hack, generally not useful and is generally
not going to get used.
It actually is being used.
On 2010-11-01 23:12, Jason van Zyl wrote:
On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote:
On 2010-11-01 22:48, Jason van Zyl wrote:
On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote:
On 2010-11-01 13:41, Jason van Zyl wrote:
In much the same way we have a little sub-project for
On 2010-11-01 23:18, Jason van Zyl wrote:
On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote:
On 2010-11-01 22:48, Jason van Zyl wrote:
On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote:
On 2010-11-01 13:41, Jason van Zyl wrote:
In much the same way we have a little sub-project for
On 2010-11-01 23:19, Vincent Siveton wrote:
2010/11/1 Jason van Zyl ja...@maven.org:
On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
Hi,
I agree in the fact to move unmaintened plugins but god, why are you
so quick one more time!
You asked Dennis to create a wiki page but you already
On 1 November 2010 22:26, Dennis Lundberg denn...@apache.org wrote:
The separation of concerns is a worthy goal. Like I wrote in another
mail I think some B+R plugins have their build and reporting code
intertwined. Splitting that up might be difficult and we could end up
with a bunch of new
I am working on a release of Polyglot Maven and the only tangible thing
stopping me is having a plan for POM interoperability between:
1) Different representations of the model for the same version of the model.
This is what I'd like for the first version of Polyglot Maven where I just want
to
On 1 November 2010 21:37, Dennis Lundberg denn...@apache.org wrote:
On 2010-11-01 22:10, Stephen Connolly wrote:
Then -1 the commits.
We have a commit first, ask forgiveness second policy in maven last time I
checked
So do you think that it's OK for someone to pull the rug from under your
+1
On 1 November 2010 21:51, Brian Fox bri...@infinity.nu wrote:
I'm preparing the enforcer release and it needs the latest parent
changes, so I've cut a release:
Staged parent:
Hi
I'm looking into releasing Wagon and Brett suggested that I try the new
version in a Maven build to make sure everything is building fine.
So I checked out the 2.2.x branch tried to build it prior to maing any
changes, by running:
mvn install -Prun-its
All is fine until it gets to Building
+1
On 1 November 2010 21:35, Dennis Lundberg denn...@apache.org wrote:
Hi
Given the discussions about retiring plugin I feel strongly that we need
to have a plan for doing so. There are bound to be differing opinions
about this, so see this as a starting point for discussions. When we get
On 1 November 2010 22:32, Dennis Lundberg denn...@apache.org wrote:
That is something we need to add to the process. But until the process
has been finalized I think we should revert the svn moves.
+1
In the absense of a process, since retirement is essentially an SVN
operation, then our
On Nov 1, 2010, at 11:24 PM, Dan Tran wrote:
On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl ja...@maven.org wrote:
On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote:
On 2010-11-01 18:54, Jason van Zyl wrote:
Doesn't change the fact it's a hack, generally not useful and is generally
not
On Nov 1, 2010, at 11:19 PM, Vincent Siveton wrote:
2010/11/1 Jason van Zyl ja...@maven.org:
On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
Hi,
I agree in the fact to move unmaintened plugins but god, why are you
so quick one more time!
You asked Dennis to create a wiki page but
On Nov 1, 2010, at 11:32 PM, Dennis Lundberg wrote:
On 2010-11-01 23:19, Vincent Siveton wrote:
2010/11/1 Jason van Zyl ja...@maven.org:
On Nov 1, 2010, at 10:59 PM, Vincent Siveton wrote:
Hi,
I agree in the fact to move unmaintened plugins but god, why are you
so quick one more
I think we need to get use to the idea of deploying a different POM
(as XML) from the POM that is used to build.
Here are some use-cases I can see:
1. Corporate project which deploys an artifact to a public repo. Some
of the info (e.g. SCM details, developers, build, distMgmt, etc) is,
due to
+1
Arnaud
On Nov 1, 2010, at 10:51 PM, Brian Fox wrote:
I'm preparing the enforcer release and it needs the latest parent
changes, so I've cut a release:
Staged parent:
On 2010-11-01 23:50, Stephen Connolly wrote:
On 1 November 2010 22:32, Dennis Lundberg denn...@apache.org wrote:
That is something we need to add to the process. But until the process
has been finalized I think we should revert the svn moves.
+1
In the absense of a process, since
+1
- Olivier
Le 1 nov. 2010 22:52, Brian Fox bri...@infinity.nu a écrit :
I'm preparing the enforcer release and it needs the latest parent
changes, so I've cut a release:
Staged parent:
On Nov 1, 2010, at 11:59 PM, Stephen Connolly wrote:
I think we need to get use to the idea of deploying a different POM
(as XML) from the POM that is used to build.
Yes, my assumption for Polyglot is the front-end format could be anything, but
an XML 4.0.0 POM must go to the repository.
2010/11/1 Dennis Lundberg denn...@apache.org:
I've now reverted the changes in svn.
Thank Dennis to have catch up the legendary Jason's speed.
Vincent
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional
On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote:
Hi
Given the discussions about retiring plugin I feel strongly that we need
to have a plan for doing so. There are bound to be differing opinions
about this, so see this as a starting point for discussions. When we get
to the point that
I wasn't saying my use cases were in scope for polyglot's requirements.
I was saying my use cases were in scope for arguing that we deploy
multiple POM's to the repo.
one POM must always be a 4.0.0 XML representation of the project, but
it may not be the same as the other versions, as long as an
Le lundi 1 novembre 2010, Jason van Zyl a écrit :
I think they are primarily used as site plugin and as such they should move
with the site plugin. I agree there is a conflation of concerns. If
someone wants to decouple build logic from reporting logic that would be
great.
AFAIK, code for
On Nov 2, 2010, at 12:14 AM, Stephen Connolly wrote:
I wasn't saying my use cases were in scope for polyglot's requirements.
I'm talking generally for the model vN to model vN translation. Reduction is
orthogonal to translation, it's a transformation. I'm thinking along the lines
of making
I prefer to comment in Confluence where it can be captured:
https://cwiki.apache.org/confluence/display/MAVEN/Proposal+--+A+creation+and+retirement+plan+for+plugins
I added a bit about creation as well.
On Nov 1, 2010, at 10:57 PM, Dennis Lundberg wrote:
On 2010-11-01 22:38, Jason van Zyl
And I capture what votes I've seen so far.
https://cwiki.apache.org/confluence/display/MAVEN/Proposal+of+plugins+to+retire
And we can just use that as a record.
On Nov 1, 2010, at 10:57 PM, Dennis Lundberg wrote:
On 2010-11-01 22:38, Jason van Zyl wrote:
Can you put this in Confluence.
Do you want a different process and proposal process for restructuring? Like
I've proposed for the site plugin?
On Nov 1, 2010, at 10:35 PM, Dennis Lundberg wrote:
Hi
Given the discussions about retiring plugin I feel strongly that we need
to have a plan for doing so. There are bound to be
On Mon, Nov 1, 2010 at 3:46 PM, Jason van Zyl ja...@maven.org wrote:
On Nov 1, 2010, at 11:24 PM, Dan Tran wrote:
On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl ja...@maven.org wrote:
On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote:
On 2010-11-01 18:54, Jason van Zyl wrote:
Doesn't
On Nov 2, 2010, at 1:40 AM, Dan Tran wrote:
On Mon, Nov 1, 2010 at 3:46 PM, Jason van Zyl ja...@maven.org wrote:
On Nov 1, 2010, at 11:24 PM, Dan Tran wrote:
On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl ja...@maven.org wrote:
On Nov 1, 2010, at 10:12 PM, Dennis Lundberg wrote:
On
2010/11/1 Arnaud Héritier aherit...@gmail.com:
I agree.
Perhaps for some of them we could discuss to move them to mojo.codehaus.org
to let the community take the lead on them if we find some volunteers (I'm
thinking about the eclipse plugin for example).
It probably needs to be said that if
If you happen to find yourself in Atlanta on Wed, Nov 3rd at 8pm, and
want to talk about Maven, come join the meetup. You can find details
and the signup page here:
http://na.apachecon.com/c/acna2010/schedule/meetups
-
To
On Nov 2, 2010, at 2:31 AM, Brian Fox wrote:
2010/11/1 Arnaud Héritier aherit...@gmail.com:
I agree.
Perhaps for some of them we could discuss to move them to mojo.codehaus.org
to let the community take the lead on them if we find some volunteers (I'm
thinking about the eclipse plugin for
The barrier to collaboration is high here.
That's all I'm saying. The tools make that partially true but it's not
stopping other projects so it's clearly not the only issue. Maybe no
one really cares about these plugins, and for the ones raised so far,
that's probably the case.
I'm not sure I understand. Is the proposal here to deploy non-XML project
descriptors to the repository in addition to the standard pom? If so, what is
the point? Many projects aren't going to bother creating multiple dialects of
poms and so the variations will still have to handle the
On Nov 2, 2010, at 3:29 AM, Ralph Goers wrote:
I'm not sure I understand. Is the proposal here to deploy non-XML project
descriptors to the repository in addition to the standard pom? If so, what
is the point?
In the case of the Clojure dialect there will be two other implementations
On Mon, Nov 1, 2010 at 5:59 PM, Jason van Zyl ja...@maven.org wrote:
On Nov 2, 2010, at 1:40 AM, Dan Tran wrote:
On Mon, Nov 1, 2010 at 3:46 PM, Jason van Zyl ja...@maven.org wrote:
On Nov 1, 2010, at 11:24 PM, Dan Tran wrote:
On Mon, Nov 1, 2010 at 2:15 PM, Jason van Zyl ja...@maven.org
On Nov 1, 2010, at 7:36 PM, Jason van Zyl wrote:
On Nov 2, 2010, at 3:29 AM, Ralph Goers wrote:
I'm not sure I understand. Is the proposal here to deploy non-XML project
descriptors to the repository in addition to the standard pom? If so, what
is the point?
In the case of the
I personally think deprecating/retiring the eclipse plugin is a bit premature.
Looking at the svn log, there have been a buunch of commits and a release this
year, so there definitely are people that are supporting it.
Maybe if m2eclipse was actually usable for any of the projects I work
+1 on keeping the eclipse plugin. I like m2Eclipse but at times is
buggy so I fall back to using this often.
Paul
2010/11/1 Daniel Kulp dk...@apache.org:
I personally think deprecating/retiring the eclipse plugin is a bit premature.
Looking at the svn log, there have been a buunch of commits
1 - 100 of 101 matches
Mail list logo
