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 2007/06/05 03:13:21 UTC
Re: packaging
On 05/06/2007, at 11:01 AM, Carlos Sanchez wrote:
> I noticed the issue with duplicated packages while playing with OSGi
> but is not directly related.
> The fact that we have same packages in different modules is just a bad
> practice, for architectural and easier development issues. If I see an
> org.apache.maven.project class I'd look into maven-project without
> having to search all the sources
Thinking purely from a packaging perspective, I agree with the
principle but not the implementation. I didn't like the look of a
'core' package and was planning on commenting myself. (I only had a
brief look at the commits didn't spend any more time with it after it
was reverted until the discussion came up).
I think we need to take a more critical look at how the packages are
structured to make sure each module is properly self-contained and
has a well-defined public API. I think this should this be an
architectural goal for 2.1.
I think it's great that we have things like the embedder which can be
a simple, single point of entry for someone that uses all of Maven,
but I don't ever want to lose the ability to consume discreet pieces
of functionality like the artifact mechanism.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: packaging
Posted by Jason van Zyl <ja...@maven.org>.
On 5 Jun 07, at 10:23 PM 5 Jun 07, Carlos Sanchez wrote:
>
> there's many tools, libraries, etc out there that use the libraries, i
> don't see why we have to limit this use in any way
>
I don't think that's the case. It's primarily the embedder in the 17
cases of IDE integration and products that use Maven. The rest of the
tooling I see is based around plugins. I think people stay clear of
the components primarily because the APIs are scary. Who can't use
the embedder?
>>
>> > - Brett
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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 and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> 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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: packaging
Posted by Carlos Sanchez <ca...@apache.org>.
On 6/5/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 4 Jun 07, at 9:13 PM 4 Jun 07, Brett Porter wrote:
>
> >
> > On 05/06/2007, at 11:01 AM, Carlos Sanchez wrote:
> >
> >> I noticed the issue with duplicated packages while playing with OSGi
> >> but is not directly related.
> >> The fact that we have same packages in different modules is just a
> >> bad
> >> practice, for architectural and easier development issues. If I
> >> see an
> >> org.apache.maven.project class I'd look into maven-project without
> >> having to search all the sources
> >
> > Thinking purely from a packaging perspective, I agree with the
> > principle but not the implementation. I didn't like the look of a
> > 'core' package and was planning on commenting myself. (I only had a
> > brief look at the commits didn't spend any more time with it after
> > it was reverted until the discussion came up).
> >
> > I think we need to take a more critical look at how the packages
> > are structured to make sure each module is properly self-contained
> > and has a well-defined public API. I think this should this be an
> > architectural goal for 2.1.
> >
> > I think it's great that we have things like the embedder which can
> > be a simple, single point of entry for someone that uses all of
> > Maven, but I don't ever want to lose the ability to consume
> > discreet pieces of functionality like the artifact mechanism.
> >
>
> It's already lost, in practice people are just going to consume the
> embedder. The only case where it has been used in even a vaguely
> separate fashion are the Ant Tasks are moving more and more toward a
> hybrid of Ant and Maven. Requiring syncing with the settings, proxies
> and POMs which pretty much brings in everything in the embedder. For
> simple artifact use a separate artifact library in plexus can be
> used. Anything even remotely involving Maven in practice brings
> almost all core functionality. Everyone expects syncing with
> everything else in Maven.
there's many tools, libraries, etc out there that use the libraries, i
don't see why we have to limit this use in any way
>
> > - Brett
> >
> > ---------------------------------------------------------------------
> > 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 and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: packaging
Posted by Jason van Zyl <ja...@maven.org>.
On 4 Jun 07, at 9:13 PM 4 Jun 07, Brett Porter wrote:
>
> On 05/06/2007, at 11:01 AM, Carlos Sanchez wrote:
>
>> I noticed the issue with duplicated packages while playing with OSGi
>> but is not directly related.
>> The fact that we have same packages in different modules is just a
>> bad
>> practice, for architectural and easier development issues. If I
>> see an
>> org.apache.maven.project class I'd look into maven-project without
>> having to search all the sources
>
> Thinking purely from a packaging perspective, I agree with the
> principle but not the implementation. I didn't like the look of a
> 'core' package and was planning on commenting myself. (I only had a
> brief look at the commits didn't spend any more time with it after
> it was reverted until the discussion came up).
>
> I think we need to take a more critical look at how the packages
> are structured to make sure each module is properly self-contained
> and has a well-defined public API. I think this should this be an
> architectural goal for 2.1.
>
> I think it's great that we have things like the embedder which can
> be a simple, single point of entry for someone that uses all of
> Maven, but I don't ever want to lose the ability to consume
> discreet pieces of functionality like the artifact mechanism.
>
It's already lost, in practice people are just going to consume the
embedder. The only case where it has been used in even a vaguely
separate fashion are the Ant Tasks are moving more and more toward a
hybrid of Ant and Maven. Requiring syncing with the settings, proxies
and POMs which pretty much brings in everything in the embedder. For
simple artifact use a separate artifact library in plexus can be
used. Anything even remotely involving Maven in practice brings
almost all core functionality. Everyone expects syncing with
everything else in Maven.
> - Brett
>
> ---------------------------------------------------------------------
> 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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: packaging
Posted by Carlos Sanchez <ca...@apache.org>.
On 6/4/07, Brett Porter <br...@apache.org> wrote:
>
> On 05/06/2007, at 11:01 AM, Carlos Sanchez wrote:
>
> > I noticed the issue with duplicated packages while playing with OSGi
> > but is not directly related.
> > The fact that we have same packages in different modules is just a bad
> > practice, for architectural and easier development issues. If I see an
> > org.apache.maven.project class I'd look into maven-project without
> > having to search all the sources
>
> Thinking purely from a packaging perspective, I agree with the
> principle but not the implementation. I didn't like the look of a
> 'core' package and was planning on commenting myself. (I only had a
> brief look at the commits didn't spend any more time with it after it
> was reverted until the discussion came up).
I'm open to suggestions for package names for maven-core, but the
other ones are pretty obvious
>
> I think we need to take a more critical look at how the packages are
> structured to make sure each module is properly self-contained and
> has a well-defined public API. I think this should this be an
> architectural goal for 2.1.
ok so what are we going to do to keep backwards compatibility without
adding complexity to patching
- just make new classes in the new packages and old ones extend them
- merging that to the 2.0.x branch too to reduce differences between them
- make the new classes extend the old ones so all the code is in the old ones
>
> I think it's great that we have things like the embedder which can be
> a simple, single point of entry for someone that uses all of Maven,
> but I don't ever want to lose the ability to consume discreet pieces
> of functionality like the artifact mechanism.
we agree
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org