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 2006/09/18 01:22:59 UTC
Re: where to put common code was: [jira] Created: (MRELEASE-162) Move all release core code in maven/shared
I'm interested in opening this up for discussion. Where the code
lives doesn't really have any effect on binary artifacts - they end
up in the repository and can be used from anywhere. So I'm wondering
where it makes the most sense to put it in the source repository.
I'm inclined to say having modules under a plugin makes more sense
when they are closely related. This would be the case here.
However, there are other examples: Maven SCM is a separate set of
libraries, and the plugin resides with that (basically the same
structure as above, but in a different location). Surefire has all
the code in one place, but the plugin in the main area on its own.
The plugin tools are currently in the core, but will be moved - and
they currently are used by only the plugin-plugin, but I guess have
some scope to be used by other tools.
Of course there are components that are truly shared and not closely
related to any one plugin, such as maven-archiver, and I think that /
shared/ as an individual component makes the most sense for them as
we have now.
So, which makes the most sense to others?
[ ] separate plugin and component code (like surefire)
[ ] multi-module build of both plugin and components, located in a
"subproject" (like SCM)
[ ] multi-module build of both plugin and components, located in the
plugins directory
[ ] one big plugin jar (like the release plugin now), which can be
depended on as a regular JAR artifact as needed.
Cheers,
Brett
On 16/09/2006, at 10:03 PM, Emmanuel Venisse (JIRA) wrote:
> Move all release core code in maven/shared
> ------------------------------------------
>
> Key: MRELEASE-162
> URL: http://jira.codehaus.org/browse/MRELEASE-162
> Project: Maven 2.x Release Plugin
> Issue Type: Task
> Affects Versions: 2.0
> Reporter: Emmanuel Venisse
> Assigned To: Edwin Punzalan
> Priority: Critical
> Fix For: 2.0
>
>
> It's very important to do it because continuum use this code in
> continuum-release too and it's a bad idea to depend on a plugin.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators: http://jira.codehaus.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/
> software/jira
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: where to put common code was: [jira] Created: (MRELEASE-162) Move all release core code in maven/shared
Posted by John Casey <ca...@gmail.com>.
[ ] separate plugin and component code (like surefire)
[ x ] multi-module build of both plugin and components, located in a
"subproject" (like SCM)
[ ] multi-module build of both plugin and components, located in the
plugins directory
[ ] one big plugin jar (like the release plugin now), which can be
depended on as a regular JAR artifact as needed.
I think that once you've got some piece of functionality so large, and
you're going to implement hooks in two different systems to use it, it
should have its own space. The hooks become details, rather than defining
the functionality...so, instead of it being release-plugin functionality,
it's a set of components for software releases, which happens to have a mojo
wrapping it (and continuum bindings, too).
-j
On 9/18/06, dan tran <da...@gmail.com> wrote:
>
> [ ] separate plugin and component code (like surefire)
> [ x ] multi-module build of both plugin and components, located in a
> "subproject" (like SCM)
> [ ] multi-module build of both plugin and components, located in the
> plugins directory
> [ ] one big plugin jar (like the release plugin now), which can be
> depended on as a regular JAR artifact as needed.
>
> Plugin and its components are very much closely related to each others.
> Changes to component most likely
> would hit the plugins. Also, placing them under one parent can make
> debugging much easier when dealing with
> IDE ( ie eclipse)
>
> -D
>
> I am have been using this approach for all my components and plugins (
> internal and external)
>
>
> On 9/17/06, Brett Porter <br...@apache.org> wrote:
> >
> > I'm interested in opening this up for discussion. Where the code
> > lives doesn't really have any effect on binary artifacts - they end
> > up in the repository and can be used from anywhere. So I'm wondering
> > where it makes the most sense to put it in the source repository.
> >
> > I'm inclined to say having modules under a plugin makes more sense
> > when they are closely related. This would be the case here.
> >
> > However, there are other examples: Maven SCM is a separate set of
> > libraries, and the plugin resides with that (basically the same
> > structure as above, but in a different location). Surefire has all
> > the code in one place, but the plugin in the main area on its own.
> > The plugin tools are currently in the core, but will be moved - and
> > they currently are used by only the plugin-plugin, but I guess have
> > some scope to be used by other tools.
> >
> > Of course there are components that are truly shared and not closely
> > related to any one plugin, such as maven-archiver, and I think that /
> > shared/ as an individual component makes the most sense for them as
> > we have now.
> >
> > So, which makes the most sense to others?
> >
> > [ ] separate plugin and component code (like surefire)
> > [ ] multi-module build of both plugin and components, located in a
> > "subproject" (like SCM)
> > [ ] multi-module build of both plugin and components, located in the
> > plugins directory
> > [ ] one big plugin jar (like the release plugin now), which can be
> > depended on as a regular JAR artifact as needed.
> >
> > Cheers,
> > Brett
> >
> > On 16/09/2006, at 10:03 PM, Emmanuel Venisse (JIRA) wrote:
> >
> > > Move all release core code in maven/shared
> > > ------------------------------------------
> > >
> > > Key: MRELEASE-162
> > > URL: http://jira.codehaus.org/browse/MRELEASE-162
> > > Project: Maven 2.x Release Plugin
> > > Issue Type: Task
> > > Affects Versions: 2.0
> > > Reporter: Emmanuel Venisse
> > > Assigned To: Edwin Punzalan
> > > Priority: Critical
> > > Fix For: 2.0
> > >
> > >
> > > It's very important to do it because continuum use this code in
> > > continuum-release too and it's a bad idea to depend on a plugin.
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > If you think it was sent incorrectly contact one of the
> > > administrators: http://jira.codehaus.org/secure/Administrators.jspa
> > > -
> > > For more information on JIRA, see: http://www.atlassian.com/
> > > software/jira
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
Re: where to put common code was: [jira] Created: (MRELEASE-162) Move all release core code in maven/shared
Posted by dan tran <da...@gmail.com>.
[ ] separate plugin and component code (like surefire)
[ x ] multi-module build of both plugin and components, located in a
"subproject" (like SCM)
[ ] multi-module build of both plugin and components, located in the
plugins directory
[ ] one big plugin jar (like the release plugin now), which can be
depended on as a regular JAR artifact as needed.
Plugin and its components are very much closely related to each others.
Changes to component most likely
would hit the plugins. Also, placing them under one parent can make
debugging much easier when dealing with
IDE ( ie eclipse)
-D
I am have been using this approach for all my components and plugins (
internal and external)
On 9/17/06, Brett Porter <br...@apache.org> wrote:
>
> I'm interested in opening this up for discussion. Where the code
> lives doesn't really have any effect on binary artifacts - they end
> up in the repository and can be used from anywhere. So I'm wondering
> where it makes the most sense to put it in the source repository.
>
> I'm inclined to say having modules under a plugin makes more sense
> when they are closely related. This would be the case here.
>
> However, there are other examples: Maven SCM is a separate set of
> libraries, and the plugin resides with that (basically the same
> structure as above, but in a different location). Surefire has all
> the code in one place, but the plugin in the main area on its own.
> The plugin tools are currently in the core, but will be moved - and
> they currently are used by only the plugin-plugin, but I guess have
> some scope to be used by other tools.
>
> Of course there are components that are truly shared and not closely
> related to any one plugin, such as maven-archiver, and I think that /
> shared/ as an individual component makes the most sense for them as
> we have now.
>
> So, which makes the most sense to others?
>
> [ ] separate plugin and component code (like surefire)
> [ ] multi-module build of both plugin and components, located in a
> "subproject" (like SCM)
> [ ] multi-module build of both plugin and components, located in the
> plugins directory
> [ ] one big plugin jar (like the release plugin now), which can be
> depended on as a regular JAR artifact as needed.
>
> Cheers,
> Brett
>
> On 16/09/2006, at 10:03 PM, Emmanuel Venisse (JIRA) wrote:
>
> > Move all release core code in maven/shared
> > ------------------------------------------
> >
> > Key: MRELEASE-162
> > URL: http://jira.codehaus.org/browse/MRELEASE-162
> > Project: Maven 2.x Release Plugin
> > Issue Type: Task
> > Affects Versions: 2.0
> > Reporter: Emmanuel Venisse
> > Assigned To: Edwin Punzalan
> > Priority: Critical
> > Fix For: 2.0
> >
> >
> > It's very important to do it because continuum use this code in
> > continuum-release too and it's a bad idea to depend on a plugin.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the
> > administrators: http://jira.codehaus.org/secure/Administrators.jspa
> > -
> > For more information on JIRA, see: http://www.atlassian.com/
> > software/jira
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>