You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2008/12/15 06:55:27 UTC
Re: external components was: svn commit: r726521
On 15/12/2008, at 6:51 AM, jvanzyl@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=726521&r1=726520&r2=726521&view=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>
> - <groupId>org.apache.maven.shared</groupId>
> - <artifactId>maven-shared-model</artifactId>
> + <groupId>org.sonatype.spice</groupId>
> + <artifactId>model-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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: external components was: svn commit: r726521
Posted by Benjamin Bentmann <be...@udo.edu>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: external components was: svn commit: r726521
Posted by Shane Isbell <sh...@gmail.com>.
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, jvanzyl@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=726521&r1=726520&r2=726521&view=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>
>> - <groupId>org.apache.maven.shared</groupId>
>> - <artifactId>maven-shared-model</artifactId>
>> + <groupId>org.sonatype.spice</groupId>
>> + <artifactId>model-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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: external components was: svn commit: r726521
Posted by Arnaud HERITIER <ah...@gmail.com>.
+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 <ra...@dslextreme.com>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.
>
> Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: external components was: svn commit: r726521
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: external components was: svn commit: r726521
Posted by Jason van Zyl <jv...@sonatype.com>.
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>
>> - <groupId>org.apache.maven.shared</groupId>
>> - <artifactId>maven-shared-model</artifactId>
>> + <groupId>org.sonatype.spice</groupId>
>> + <artifactId>model-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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org