Re: external components was: svn commit: r726521
Shane Isbell wrote: I talked with Jason last month about moving and renaming maven-shared-model Given that the code has moved, does the code in the shared area [0] serve any purpose or can it be deleted? Benjamin [0] https://svn.apache.org/repos/asf/maven/shared/trunk/maven-shared-model - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: external components was: svn commit: r726521
On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote: Also in the course of 6 months of development of the model-builder we have not had a single contribution from anyone else. Zero interest. So yes, it is easier to release elsewhere and that has allowed me to patch, test, release in rapid succession to try and get the alpha-1 to the point of release. I wouldn't say zero interest. I simply have found it impossible to keep up with all the svn commits in all the various branches. Furthermore, a lot of stuff was being worked on in somewhat private branches. Unless they ask for collaboration I'm not going to go review stuff in someone's private sandbox until they call out and say it is ready for review before merging. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: external components was: svn commit: r726521
On 16/12/2008, at 7:50 PM, Ralph Goers wrote: On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote: Also in the course of 6 months of development of the model-builder we have not had a single contribution from anyone else. Zero interest. So yes, it is easier to release elsewhere and that has allowed me to patch, test, release in rapid succession to try and get the alpha-1 to the point of release. I wouldn't say zero interest. I simply have found it impossible to keep up with all the svn commits in all the various branches. Furthermore, a lot of stuff was being worked on in somewhat private branches. Unless they ask for collaboration I'm not going to go review stuff in someone's private sandbox until they call out and say it is ready for review before merging. Yes, exactly. I don't particularly care if the code is put somewhere else. The license allows it and I'm not particularly attached to my single trivial commit. I do care if we start introducing dependencies from external sources without setting a higher barrier. If it were anything like Woodstox where it was pretty much baked and clear what to do if you have a problem then it'd be fine. But if it's going to be outside the project (particularly where some people don't have commit access) we can't chase snapshots. The situation with Modello and Plexus is not an ideal way to continue doing things given the chance to change, no matter how easy it is to get commit or how easy it is to get the whole chain of dependencies up in an IDE. Even if the code of the model-builder is completely stable, it needs more work: - there's no site or documentation to go with it (from what I can tell, all the documentation is in the PDF which is now in Maven) - there's no issue tracker to report problems to (I found SPICE though it's not listed in the POM, but it doesn't have a component) - there's no way to find out where it is going next or ask questions. That's either going to happen here (in which case, why move?), or need to be done privately with Shane (which is not scalable). The fact that it was released (as 1.0) like that, without changing the packages or the license made it look to me like it was the right thing done at the wrong time for the wrong reasons. Given that, it was just hard to tell what was going on - though it is helpful that it has been made clear that nothing else is going to be moved now. Thanks, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: external components was: svn commit: r726521
+1 It's too difficult to follow what it is done in 2.0.X, 2.X and 3.X in the same time without working on it every day. Arnaud On Tue, Dec 16, 2008 at 9:50 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote: Also in the course of 6 months of development of the model-builder we have not had a single contribution from anyone else. Zero interest. So yes, it is easier to release elsewhere and that has allowed me to patch, test, release in rapid succession to try and get the alpha-1 to the point of release. I wouldn't say zero interest. I simply have found it impossible to keep up with all the svn commits in all the various branches. Furthermore, a lot of stuff was being worked on in somewhat private branches. Unless they ask for collaboration I'm not going to go review stuff in someone's private sandbox until they call out and say it is ready for review before merging. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- .. Arnaud HERITIER 12 guidelines to boost your productivity with a Java software factory - http://tinyurl.com/56s9tw .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: external components was: svn commit: r726521
On 15-Dec-08, at 12:55 AM, Brett Porter wrote:
=
=
--- maven/components/trunk/maven-core/pom.xml (original)
+++ maven/components/trunk/maven-core/pom.xml Sun Dec 14 11:51:59
2008
@@ -111,8 +111,8 @@
version${project.version}/version
/dependency
dependency
- groupIdorg.apache.maven.shared/groupId
- artifactIdmaven-shared-model/artifactId
+ groupIdorg.sonatype.spice/groupId
+ artifactIdmodel-builder/artifactId
/dependency
/dependencies
build
I can't believe I even have to say this, but moving components
critical to the function of Maven out of our subversion repository
is not a way to solve the problem of unreleased snapshots, IMO. Can
you explain to me how this is anything other than a move to route
around Apache's release rules? Why couldn't it be done where it was?
Nothing in there is Maven specific in the slightest. We are using that
component in NMaven (not here), Byldan (not here), Nexus and Hudson.
It's general XML manipulation.
For something like Mercury which is related to dependency management
it is obviously in the domain of Maven. XML manipulation is not.
Also in the course of 6 months of development of the model-builder we
have not had a single contribution from anyone else. Zero interest. So
yes, it is easier to release elsewhere and that has allowed me to
patch, test, release in rapid succession to try and get the alpha-1 to
the point of release.
I don't buy the argument that it's because it's useful outside of
Maven, since one of the great things about Maven is that anyone can
reuse it no matter what it is called. Considering the licenses and
packages weren't even changed from o.a.m.shared and the ASF header
for a version 1.0, I guess that's not the issue.
Brett, I'm honestly more interested in servicing the user community
and that means getting releases out. I mean honestly Brett what right
do you really have over the domain of this code? And are you worried
that folks who want to work on it aren't going to get access? Come on.
Anyone who has ever wanted contribute to Plexus or Modello from the
Maven side has never had a problem and the libraries at Sonatype are
not going to be any different. No different then Codehaus except we
have more control over the infrastructure like the repositories and CI.
This is no different then Woodstox which is 1-2 guys at Codehaus. If
anyone wanted access from Dan or Tatu it wouldn't be a problem, but
I've never gone hacking in Woodstox so I don't need it.
Like Plexus, I know well enough how often developing on Maven is
going to require digging into the code for such dependencies as this
and the plugin manager, and probably making changes to fix bugs in
the future. This move will be a barrier to some of the Maven
committers.
With m2eclipse, ( and probably Netbeans, or IDEA) everything is
available visually and easy to materialize by right clicking on a
dependency. I also plan to make a project materialization descriptor
for Maven so no one is going to have to go hunting for anything in
Maven. If anyone wants access to the sources to debug it will be dead
simple. Tim will be writing a developer guide so I think historically
this will become the easiest, most documented way to develop Maven.
That will be available by alpha 3 or 4.
I want to encourage more people to work on the core, but again in the
last 6 months I can count on one hand the number of people who have
worked on the core.
So I really don't think the location of libraries is the barrier.
We need a deadly fast way to get new potential developers initialized
and get working with the code almost immediately.
Could you please make clear what your intentions are? Are you
intending to move anything else?
For 3.x the dependency set is all releases now and we have all the
components we need. Once I release the alpha-1 the current location of
dependencies won't change. I imagine most of the work will happen WRT
Mercury, and I honestly don't see any additional dependencies being
needed for 3.x itself. I'll reduce them if it goes in any direction.
For the transitive dependencies underneath when Plexus is 1.0 I would
still like to move that to Apache. The XWiki folks are waiting for
this, and after chatting with some folks it would also make the
Eclipse IP work easier in the future for m2eclipse.
Thanks,
Brett
--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
--
We all have
Re: external components was: svn commit: r726521
On 15/12/2008, at 6:51 AM, jvan...@apache.org wrote:
Modified: maven/components/trunk/maven-core/pom.xml
URL:
http://svn.apache.org/viewvc/maven/components/trunk/maven-core/pom.xml?rev=726521r1=726520r2=726521view=diff
=
=
=
=
=
=
=
=
==
--- maven/components/trunk/maven-core/pom.xml (original)
+++ maven/components/trunk/maven-core/pom.xml Sun Dec 14 11:51:59 2008
@@ -111,8 +111,8 @@
version${project.version}/version
/dependency
dependency
- groupIdorg.apache.maven.shared/groupId
- artifactIdmaven-shared-model/artifactId
+ groupIdorg.sonatype.spice/groupId
+ artifactIdmodel-builder/artifactId
/dependency
/dependencies
build
I can't believe I even have to say this, but moving components
critical to the function of Maven out of our subversion repository is
not a way to solve the problem of unreleased snapshots, IMO. Can you
explain to me how this is anything other than a move to route around
Apache's release rules? Why couldn't it be done where it was?
I don't buy the argument that it's because it's useful outside of
Maven, since one of the great things about Maven is that anyone can
reuse it no matter what it is called. Considering the licenses and
packages weren't even changed from o.a.m.shared and the ASF header for
a version 1.0, I guess that's not the issue.
Like Plexus, I know well enough how often developing on Maven is going
to require digging into the code for such dependencies as this and the
plugin manager, and probably making changes to fix bugs in the future.
This move will be a barrier to some of the Maven committers.
Could you please make clear what your intentions are? Are you
intending to move anything else?
Thanks,
Brett
--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: external components was: svn commit: r726521
I talked with Jason last month about moving and renaming maven-shared-model,
as the component is completely general. It allows people to handle
inheritance, interpolation and transforms on any model in any format. Jason
pinged me before the move and I was in favor of it. It's much clearer to
people the intent and use of the component if it is outside of Maven.
Shane
On Sun, Dec 14, 2008 at 9:55 PM, Brett Porter br...@apache.org wrote:
On 15/12/2008, at 6:51 AM, jvan...@apache.org wrote:
Modified: maven/components/trunk/maven-core/pom.xml
URL:
http://svn.apache.org/viewvc/maven/components/trunk/maven-core/pom.xml?rev=726521r1=726520r2=726521view=diff
=
=
=
=
=
=
=
=
==
--- maven/components/trunk/maven-core/pom.xml (original)
+++ maven/components/trunk/maven-core/pom.xml Sun Dec 14 11:51:59 2008
@@ -111,8 +111,8 @@
version${project.version}/version
/dependency
dependency
- groupIdorg.apache.maven.shared/groupId
- artifactIdmaven-shared-model/artifactId
+ groupIdorg.sonatype.spice/groupId
+ artifactIdmodel-builder/artifactId
/dependency
/dependencies
build
I can't believe I even have to say this, but moving components critical to
the function of Maven out of our subversion repository is not a way to solve
the problem of unreleased snapshots, IMO. Can you explain to me how this is
anything other than a move to route around Apache's release rules? Why
couldn't it be done where it was?
I don't buy the argument that it's because it's useful outside of Maven,
since one of the great things about Maven is that anyone can reuse it no
matter what it is called. Considering the licenses and packages weren't even
changed from o.a.m.shared and the ASF header for a version 1.0, I guess
that's not the issue.
Like Plexus, I know well enough how often developing on Maven is going to
require digging into the code for such dependencies as this and the plugin
manager, and probably making changes to fix bugs in the future. This move
will be a barrier to some of the Maven committers.
Could you please make clear what your intentions are? Are you intending to
move anything else?
Thanks,
Brett
--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
