You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2005/12/05 21:58:26 UTC
[all] Sharing maven setup [was Re: HELP!]
>>I don't much like the idea of adding dependencies to each of the
>>individual POMs, but understand that this makes the dependency
>>explicit, which is a good thing. So I guess I am +0 for this
>>approach. Actually +1 as in "will help" if others agree we should go
>>this route instead of the updatePlugins approach.
>
> I'm more than happy with the updatePlugins approach. It's KISS at its best.
> ;-)
>
> I remain -1 on reverting to extending the commons-build POM
I agree that we should not extend the commons-build POM. However we
could do with a way to share stuff.
I have in my mind that what we need is a commons maven plugin. It would:
- create target/commons
- download commons-build within target/commons
- update the local maven installation
- merge the latest mandatory POM settings
- merge the latest mandatory POM properties
- merge the latest mandatory xdocs
Thus, to push a site or release out you do:
maven commons
then any other command:
maven ...
This is probably a pipedream though, as I doubt anyone has the time to
write this (ie. I don't!)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Dennis Lundberg <de...@mdh.se>.
Phil Steitz wrote:
> Dennis,
>
> Thanks!! +1 for the commons-plugin. See comments interspersed. One
> thing to keep in mind is to try to keep it as simple as possible. I
> think we got a little too complicated in the site generation stuff and
> it has been a pain to maintain. Other nice-to-haves are ease of
> migration to maven 2 and reusability outside of commons (group of
> related, but independent projects wanting to share some common
> resources).
>
> On 12/5/05, Dennis Lundberg <de...@mdh.se> wrote:
> <snip>
>>>> I remain -1 on reverting to extending the commons-build POM
>>> I agree that we should not extend the commons-build POM. However we
>>> could do with a way to share stuff.
>
> Yes, the trick is how to do this while keeping projects self-contained.
Exactly.
>>> I have in my mind that what we need is a commons maven plugin. It would:
>>> - create target/commons
>>> - download commons-build within target/commons
>>> - update the local maven installation
>>> - merge the latest mandatory POM settings
>>> - merge the latest mandatory POM properties
>>> - merge the latest mandatory xdocs
>>>
>>> Thus, to push a site or release out you do:
>>> maven commons
>>> then any other command:
>>> maven ...
>>>
>>> This is probably a pipedream though, as I doubt anyone has the time to
>>> write this (ie. I don't!)
>> Yes, of course! A plugin is the way to go.
>>
>> Most people seems to agree that extending commons-build is a bad thing,
>> so we need to figure out a way to make each commons component
>> self-supporting.
>>
>> Imagine this directory structure in the commons component of your choice:
>>
>> /
>> +- commons-<component>/
>> +- site/
>> | +- menus/
>> | | +- ...
>> | +- parts/
>> | | +- ...
>> | +- commons-site.jsl
>> | +- cvsusage.xml
>> | +- ...
>> +- project.properties
>> +- project.xml
>> +- project-parent.xml
>>
>> First we make sure that every commons-component extends the *local*
>> project-parent.xml, see directory-structure above. This would be a
>> one-time job.
>>
>> If we then create a plugin that does the following, it might just work:
>>
>> - Download commons-build/project-parent.xml via anonymous SVN to
>> commons-<component>/project-parent.xml
>> - We would probably need to do something similar for project.properties,
>> I'm not sure how that would work though
>> - Download commons-build/site/menus/ , commons-build/site/parts/ et al
>> via anonymous SVN to commons-<component>/site/
>>
>> This way we don't have to think about merging xml documents and other
>> fancy stuff - just download some files from SVN.
>>
>> Does this sound at all possible?
>
> Definitiely sounds doable and reasonable to me; with the exception of
> the POM inheritance bit. I am not yet 100% convinced of the need for
> project-parent and I am not sure about the consequences of this from a
> maven repo standpoint. I don't know if you can inherit from an
> "abstract" POM or even if such a thing exists - i.e., IIUC your
> project-parent would have to have a groupID/artifactID and the local
> repo (and eventually apache/ibiblio) might get corrupted/confused, as
> this could change over time. The latter actually is the core of the
> issue - in order for the releases to be really self-contained, either
> we have to tag and version the common stuff with each component
> release, or they need to be able to essentially fork it (as they more
> or less do now).
My idea was to actually check in all of the common bits and pieces into
each and every commons-component. The job of keeping these bits updated
would be handled by the plugin. That way the tagging would be solved by
each component. It would mean a lot of copies of these common files, but
I don't see that as a problem.
We would need to add a mandatory step in the release cycle to run the
commons-plugin and check in the common files that have changed.
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Phil Steitz <ph...@gmail.com>.
Dennis,
Thanks!! +1 for the commons-plugin. See comments interspersed. One
thing to keep in mind is to try to keep it as simple as possible. I
think we got a little too complicated in the site generation stuff and
it has been a pain to maintain. Other nice-to-haves are ease of
migration to maven 2 and reusability outside of commons (group of
related, but independent projects wanting to share some common
resources).
On 12/5/05, Dennis Lundberg <de...@mdh.se> wrote:
<snip>
> >> I remain -1 on reverting to extending the commons-build POM
> >
> > I agree that we should not extend the commons-build POM. However we
> > could do with a way to share stuff.
Yes, the trick is how to do this while keeping projects self-contained.
> >
> > I have in my mind that what we need is a commons maven plugin. It would:
> > - create target/commons
> > - download commons-build within target/commons
> > - update the local maven installation
> > - merge the latest mandatory POM settings
> > - merge the latest mandatory POM properties
> > - merge the latest mandatory xdocs
> >
> > Thus, to push a site or release out you do:
> > maven commons
> > then any other command:
> > maven ...
> >
> > This is probably a pipedream though, as I doubt anyone has the time to
> > write this (ie. I don't!)
>
> Yes, of course! A plugin is the way to go.
>
> Most people seems to agree that extending commons-build is a bad thing,
> so we need to figure out a way to make each commons component
> self-supporting.
>
> Imagine this directory structure in the commons component of your choice:
>
> /
> +- commons-<component>/
> +- site/
> | +- menus/
> | | +- ...
> | +- parts/
> | | +- ...
> | +- commons-site.jsl
> | +- cvsusage.xml
> | +- ...
> +- project.properties
> +- project.xml
> +- project-parent.xml
>
> First we make sure that every commons-component extends the *local*
> project-parent.xml, see directory-structure above. This would be a
> one-time job.
>
> If we then create a plugin that does the following, it might just work:
>
> - Download commons-build/project-parent.xml via anonymous SVN to
> commons-<component>/project-parent.xml
> - We would probably need to do something similar for project.properties,
> I'm not sure how that would work though
> - Download commons-build/site/menus/ , commons-build/site/parts/ et al
> via anonymous SVN to commons-<component>/site/
>
> This way we don't have to think about merging xml documents and other
> fancy stuff - just download some files from SVN.
>
> Does this sound at all possible?
Definitiely sounds doable and reasonable to me; with the exception of
the POM inheritance bit. I am not yet 100% convinced of the need for
project-parent and I am not sure about the consequences of this from a
maven repo standpoint. I don't know if you can inherit from an
"abstract" POM or even if such a thing exists - i.e., IIUC your
project-parent would have to have a groupID/artifactID and the local
repo (and eventually apache/ibiblio) might get corrupted/confused, as
this could change over time. The latter actually is the core of the
issue - in order for the releases to be really self-contained, either
we have to tag and version the common stuff with each component
release, or they need to be able to essentially fork it (as they more
or less do now).
I do like the idea of copying in the commons-build pieces at build
time using the scm plugin or somesuch. That can help us untangle the
current navigation mess, among other things. To get around the
tagging / versioning problem, I have thought about suggesting in the
past that we check local copies into release branches and tag these as
part of releases. So, when working in trunk you do something like
what you have described above, but then when cutting a release, you
create an svn release branch that includes the local copies. These
then go into the release tag and you can later duplicate the release
from the tag. The plugin could support a branch goal that would
create the release branch with the local stuff in it.
>
> Should I have go at it? I have not made a plugin before, but there's a
> first time for everything...
>
Agree with Robert's comments below. I will chime in as time and
knowledge permits :-)
Have a look at the jdiff and changelog plugins for examples of how to
use the scm stuff.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Dennis Lundberg <de...@mdh.se>.
robert burrell donkin wrote:
<snip/>
>> Does this sound at all possible?
>
> dunno :)
>
> probably a good idea to hook up with brett and the rest of the maveneers
> on IRC (if you can).
Will try to do that.
Can you recommend a good IRV client for Windows?
>> Should I have go at it? I have not made a plugin before, but there's a
>> first time for everything...
>
> +1
>
> but don't waste too much energy: better to let folks take a look at a
> quick proof of concept early.
Noted.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2005-12-05 at 23:04 +0100, Dennis Lundberg wrote:
> Stephen Colebourne wrote:
> >>> I don't much like the idea of adding dependencies to each of the
> >>> individual POMs, but understand that this makes the dependency
> >>> explicit, which is a good thing. So I guess I am +0 for this
> >>> approach. Actually +1 as in "will help" if others agree we should go
> >>> this route instead of the updatePlugins approach.
> >>
> >> I'm more than happy with the updatePlugins approach. It's KISS at its
> >> best.
> >> ;-)
> >>
> >> I remain -1 on reverting to extending the commons-build POM
> >
> > I agree that we should not extend the commons-build POM. However we
> > could do with a way to share stuff.
> >
> > I have in my mind that what we need is a commons maven plugin. It would:
> > - create target/commons
> > - download commons-build within target/commons
> > - update the local maven installation
> > - merge the latest mandatory POM settings
> > - merge the latest mandatory POM properties
> > - merge the latest mandatory xdocs
> >
> > Thus, to push a site or release out you do:
> > maven commons
> > then any other command:
> > maven ...
> >
> > This is probably a pipedream though, as I doubt anyone has the time to
> > write this (ie. I don't!)
>
> Yes, of course! A plugin is the way to go.
+1
> Most people seems to agree that extending commons-build is a bad thing,
> so we need to figure out a way to make each commons component
> self-supporting.
i suspect that the opinion that this was a bad thing took hold in the
early days of maven after problems which didn't get fixed easily.
> Imagine this directory structure in the commons component of your choice:
>
> /
> +- commons-<component>/
> +- site/
> | +- menus/
> | | +- ...
> | +- parts/
> | | +- ...
> | +- commons-site.jsl
> | +- cvsusage.xml
> | +- ...
> +- project.properties
> +- project.xml
> +- project-parent.xml
>
> First we make sure that every commons-component extends the *local*
> project-parent.xml, see directory-structure above. This would be a
> one-time job.
partly due to my ISP losing the plot during this last week, i've been
playing around with the better ways to build modular projects using
maven and subversion. svn:external is very useful and powerful (in
combination with maven) but only works on directories. other folks (such
as axis2) use an etc directory.
so you might find:
+- commons-<component>/
+- site/
...
+- project.properties
+- project.xml
+- etc
+- project-parent.xml
works a little better
> If we then create a plugin that does the following, it might just work:
>
> - Download commons-build/project-parent.xml via anonymous SVN to
> commons-<component>/project-parent.xml
> - We would probably need to do something similar for project.properties,
> I'm not sure how that would work though
> - Download commons-build/site/menus/ , commons-build/site/parts/ et al
> via anonymous SVN to commons-<component>/site/
>
> This way we don't have to think about merging xml documents and other
> fancy stuff - just download some files from SVN.
>
> Does this sound at all possible?
dunno :)
probably a good idea to hook up with brett and the rest of the maveneers
on IRC (if you can).
> Should I have go at it? I have not made a plugin before, but there's a
> first time for everything...
+1
but don't waste too much energy: better to let folks take a look at a
quick proof of concept early.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Dennis Lundberg <de...@mdh.se>.
Stephen Colebourne wrote:
>>> I don't much like the idea of adding dependencies to each of the
>>> individual POMs, but understand that this makes the dependency
>>> explicit, which is a good thing. So I guess I am +0 for this
>>> approach. Actually +1 as in "will help" if others agree we should go
>>> this route instead of the updatePlugins approach.
>>
>> I'm more than happy with the updatePlugins approach. It's KISS at its
>> best.
>> ;-)
>>
>> I remain -1 on reverting to extending the commons-build POM
>
> I agree that we should not extend the commons-build POM. However we
> could do with a way to share stuff.
>
> I have in my mind that what we need is a commons maven plugin. It would:
> - create target/commons
> - download commons-build within target/commons
> - update the local maven installation
> - merge the latest mandatory POM settings
> - merge the latest mandatory POM properties
> - merge the latest mandatory xdocs
>
> Thus, to push a site or release out you do:
> maven commons
> then any other command:
> maven ...
>
> This is probably a pipedream though, as I doubt anyone has the time to
> write this (ie. I don't!)
Yes, of course! A plugin is the way to go.
Most people seems to agree that extending commons-build is a bad thing,
so we need to figure out a way to make each commons component
self-supporting.
Imagine this directory structure in the commons component of your choice:
/
+- commons-<component>/
+- site/
| +- menus/
| | +- ...
| +- parts/
| | +- ...
| +- commons-site.jsl
| +- cvsusage.xml
| +- ...
+- project.properties
+- project.xml
+- project-parent.xml
First we make sure that every commons-component extends the *local*
project-parent.xml, see directory-structure above. This would be a
one-time job.
If we then create a plugin that does the following, it might just work:
- Download commons-build/project-parent.xml via anonymous SVN to
commons-<component>/project-parent.xml
- We would probably need to do something similar for project.properties,
I'm not sure how that would work though
- Download commons-build/site/menus/ , commons-build/site/parts/ et al
via anonymous SVN to commons-<component>/site/
This way we don't have to think about merging xml documents and other
fancy stuff - just download some files from SVN.
Does this sound at all possible?
Should I have go at it? I have not made a plugin before, but there's a
first time for everything...
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Torsten Curdt <tc...@apache.org>.
>> I have in my mind that what we need is a commons maven plugin. It
>> would:
>
> +1
>
> I was thinking the exact same thing.
Same here :-)
cheers
--
Torsten
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Henri Yandell <fl...@gmail.com>.
On 12/5/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >>I don't much like the idea of adding dependencies to each of the
> >>individual POMs, but understand that this makes the dependency
> >>explicit, which is a good thing. So I guess I am +0 for this
> >>approach. Actually +1 as in "will help" if others agree we should go
> >>this route instead of the updatePlugins approach.
> >
> > I'm more than happy with the updatePlugins approach. It's KISS at its best.
> > ;-)
> >
> > I remain -1 on reverting to extending the commons-build POM
>
> I agree that we should not extend the commons-build POM. However we
> could do with a way to share stuff.
>
> I have in my mind that what we need is a commons maven plugin. It would:
+1
I was thinking the exact same thing.
Maybe we can find some time to hack on it at the ApacheCon.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org