You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2006/01/05 15:31:40 UTC
[maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
On 1/5/06, Bernd Bohmann <be...@atanion.com> wrote:
> Here is a more detail description of my thoughts
>
> If myfaces is a project without separate release cycle, a possible svn
> structure:
>
> myfaces/trunk/api
> myfaces/trunk/impl
> myfaces/trunk/commons
> myfaces/trunk/tomahawk
> myfaces/trunk/sandbox
> myfaces/trunk/examples or the examples belongs to the subprojects
> myfaces/trunk/assembly or build-tool(s) with checkstyle configuration,
> assembly maven plugin...
>
> I like the parent refs in the pom.xml. I don't like the svn externals
> they are painful for branching and taging.
Can you give me the arguments for parent refs? I still haven't heard
a good reason. I'm not against the idea, I just don't know what they
give you (other then a common version.) I think we can all agree that
the externals are suboptimal. The question is what to do about it.
> If myfaces has separate release cycles, a possible structure would be:
>
> myfaces/core/trunk/api
> myfaces/core/trunk/impl
> myfaces/core/trunk/example
> myfaces/core/trunk/assembly
>
> myfaces/commons/trunk
>
> myfaces/tomahawk/trunk
> myfaces/tomahawk/trunk/example
> myfaces/tomahawk/trunk/assembly
>
>
> myfaces/sandbox/trunk
> myfaces/sandbox/trunk/example
> myfaces/sandbox/trunk/assembly
>
> maybe a
>
> myfaces/common-examples/trunk
>
> and
>
> myfaces/[build|build-tool(s)]/trunk for checkstyle pmd maven-plugins
A good start. Here is a revised proposal based on Bernd's original one
core
====
myfaces/core/trunk/api
myfaces/core/trunk/impl
myfaces/core/trunk/assembly
commons
=======
myfaces/commons/trunk
tomahawk
=======
myfaces/tomahawk/trunk
myfaces/tomahawk/trunk/example
myfaces/tomahawk/trunk/assembly
myfaces/sandbox/trunk
myfaces/sandbox/trunk/example
myfaces/sandbox/trunk/assembly
maven-tools
=========
custom maven plugins, etc.
NOTES:
I took out the examples from core. The examples are 99% tomahawk
related (other then the blank example which shows basic setup.) I
think its easier to just leave examples out of core instead of having
two copies, separate examples or svn externals.
I merged sandbox and tomahawk together. A while back we decided to
put the sandbox stuff in the tomahawk.jar. Since the sandbox is
experimental it doesn't need its own release cycle. Also, stuff moves
from sandbox to tomahawk so you will often update both anyways. The
examples for tomahawk would be the current examples (minus sandbox).
The sandbox examples would go under sandbox.
> With the second option I expect faster release cycles. This would be
> nice for a faster tobago and adf integration.
Yes faster release cycles would be good. I suppose MyFaces commons
will be released everytime *either* the core or tomahawk stuff is
released. There are bound to be minor changes either time. That
still saves us the trouble of branching, testing and merging the core
stuff.
We had talked about a core project a while ago - but as an
svn:external. I like this better. You are correct that branching and
tagging will be much easier.
> Which a snapshot repository or a mavenized released version on a maven
> repository, it should not be a problem to checkout tomahawk only and
> compile it (indepent of the first option or the second option).
I had thought about this. Is there a way to tell Maven "Use my local
repository if it is newer then the maven repository?" Things could
get kind of confusing if you are using your latest commons code in the
IDE but Maven is using the last official release ...
> Best Regards
>
> Bernd
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
> Group ID is kind of like the package spec in java, use reverse domain
> name to uniquely define your whole thing, then artifactId defines the
> individual parts. I'm thinking something like this;
>
> <groupId>org.apache.myfaces</groupId>
> <artifactId>core</artifactId>
> <version>1.1.2-SNAPSHOT</version>
>
> <groupId>org.apache.myfaces</groupId>
> <artifactId>tomahawk</artifactId>
> <version>1.3-SNAPSHOT</version>
>
> <groupId>org.apache.myfaces</groupId>
> <artifactId>commons</artifactId>
> <version>1.1.2-SNAPSHOT</version>
Didn't Bernd say there were some issues with this (everything with the
same group id?)
> then when a user wants to specify a dependency (if we have build our
> poms correctly) they could specify either tomahawk to get the
> components and the impl, or just core to get just the impl.
There's an interesting issue here. What if you use tomahawk in your
project and you want to use the RI? I guess you end up downloading
MyFaces api, impl and commons into your m2 repository (for build
purposes) but use whatever implementation you want in your WAR. That
sound right?
> I think all of them should be under a single parent pom, then we can
> easily build all of them as a group.
I agreed with you on this earlier. Single parent pom is useful for a
single list of developers, etc. Plus as you say, you can run install
on the parent pom and install everything. The only matter that
remains is whether to declare most of the dependcies there or to
repeat them as necessary in the modules that need them (the way we're
doing it now.)
>
> TTFN,
>
> -bd-
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Bill Dudney <bd...@mac.com>.
Hi Sean,
On Jan 5, 2006, at 1:33 PM, Sean Schofield wrote:
>
> I would say tomahawk and core are independent of one another.
> Actually all of the "top" level POMS would be independent of one
> another. So you would have 3 separate group ids.
>
> org.apache.myfaces.core
> org.apache.myfaces.tomahawk
> org.apache.myfaces.commons
>
> What is the significance of the group id? I know that your repository
> will have one folder for each but what else does it mean? Underneath
> the group id folder is the version right? If each of these 3 can have
> their own release cycle then I think we *must* have 3 group ids right?
>
Group ID is kind of like the package spec in java, use reverse domain
name to uniquely define your whole thing, then artifactId defines the
individual parts. I'm thinking something like this;
<groupId>org.apache.myfaces</groupId>
<artifactId>core</artifactId>
<version>1.1.2-SNAPSHOT</version>
<groupId>org.apache.myfaces</groupId>
<artifactId>tomahawk</artifactId>
<version>1.3-SNAPSHOT</version>
<groupId>org.apache.myfaces</groupId>
<artifactId>commons</artifactId>
<version>1.1.2-SNAPSHOT</version>
then when a user wants to specify a dependency (if we have build our
poms correctly) they could specify either tomahawk to get the
components and the impl, or just core to get just the impl.
I think all of them should be under a single parent pom, then we can
easily build all of them as a group.
TTFN,
-bd-
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
We probably won't be ready for a few more days yet. Right now we're
getting the build tweaked and then moving onto restoring nightly
builds. Next week will probably be more realistic.
Thanks for the offer. Stay tuned for when its ready to test and feel
free to jump in!
Sean
On 1/9/06, chemeia@gmail.com <ch...@gmail.com> wrote:
> I have some time to do a review of the mavenized site this week.
>
> Steve
>
>
> On 1/9/06, Sean Schofield <sean.schofield@gmail.com > wrote:
> > > Agreed - I have been in and out of the deve lists for the last 6
> > > weeks or so and have not had a chance to follow the discussion on
> > > commons and how we package it so that tomahawk can run on the RI. Is
> > > the idea that tomahawk would have two assemblies, one for running in
> > > the RI and one for MyFaces?
> >
> > myfaces-commons.jar is just the stuff that was in the former 'share'
> > module (code that is shared between tomahawk and impl.) The jar is
> > now to be released independently of the two projects and both the
> > myfacaces implementation distro and the tomahawk distro will contain a
> > version of myfaces-commons.jar. Most likely each release of *either*
> > the implementation or tomahawk will involve a new release of commons.
> >
> > > This is fantastic! Perhaps we could donate it to the mojo project on
> > > codehaus? That project seems to get lots of exposure and exposure
> > > never hurts :-)
> >
> > A worthy idea. We haven't gotten around to the snapshot repository
> > and a few other things like this yet but Bruno has written a plugin.
> > We just need to move it out of the test svn repo to its new home.
> >
> > > Do we want to do some QA on the site before pushing it out? Something
> > > like a nightly build of the site that someone could point a link
> > > crawler at? Just a thought. We had a somewhat lengthy discussion on
> > > this topic on the WADI incubation list but I don't think that list is
> > > archived yet. Here is the jest of what we came up with for WADI
> > > (Builder is the site builder);
> > >
> > > 1) Builder - builds site with mvn site and does an initial sanity check
> > > 2) Builder - once satisfied that the build is not a waste of anyone
> > > else's time pushes the site to an intermediate server
> > > 3) Builder - sends email to dev & user list stating that website X.X
> > > RC1 is available for review at
> http://intermediate/foo/index.html
> > > 4) Everyone interested clicks on the links reads the doc etc and
> > > files jira issues against the site
> > > 5) Repeat steps 1 - 4 until dev's are satisfied with the site
> > > 6) Builder - push the site out to official project site
> > >
> > > This is not necessary but adds a bit of safety that the pushed site
> > > is 'good'.
> > >
> > > If we had an automated link crawler we could automate that as part of
> > > continuum and get an email right after a checkin breaks the site,
> > > just another thought...
> >
> > I was thinking that we could automate the website (like we were trying
> > to do with forrest.) This way corrections to documentation and new
> > announcements get pushed out right away.
> >
> > Before we cutover to the mavenized site, an extensive review is
> > definitely in order. Also an automated link check would be nice as a
> > minimum.
> >
> > > I like assembly.
> >
> > So noted. Bernd and I aren't wild about it but we're planning on
> > keeping it for now while we get the actual build working. Then we can
> > revisit naming. He is also looking forward to continuum which I know
> > you will be happy about.
> >
> > Sean
> >
>
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by ch...@gmail.com.
I have some time to do a review of the mavenized site this week.
Steve
On 1/9/06, Sean Schofield <se...@gmail.com> wrote:
>
> > Agreed - I have been in and out of the deve lists for the last 6
> > weeks or so and have not had a chance to follow the discussion on
> > commons and how we package it so that tomahawk can run on the RI. Is
> > the idea that tomahawk would have two assemblies, one for running in
> > the RI and one for MyFaces?
>
> myfaces-commons.jar is just the stuff that was in the former 'share'
> module (code that is shared between tomahawk and impl.) The jar is
> now to be released independently of the two projects and both the
> myfacaces implementation distro and the tomahawk distro will contain a
> version of myfaces-commons.jar. Most likely each release of *either*
> the implementation or tomahawk will involve a new release of commons.
>
> > This is fantastic! Perhaps we could donate it to the mojo project on
> > codehaus? That project seems to get lots of exposure and exposure
> > never hurts :-)
>
> A worthy idea. We haven't gotten around to the snapshot repository
> and a few other things like this yet but Bruno has written a plugin.
> We just need to move it out of the test svn repo to its new home.
>
> > Do we want to do some QA on the site before pushing it out? Something
> > like a nightly build of the site that someone could point a link
> > crawler at? Just a thought. We had a somewhat lengthy discussion on
> > this topic on the WADI incubation list but I don't think that list is
> > archived yet. Here is the jest of what we came up with for WADI
> > (Builder is the site builder);
> >
> > 1) Builder - builds site with mvn site and does an initial sanity check
> > 2) Builder - once satisfied that the build is not a waste of anyone
> > else's time pushes the site to an intermediate server
> > 3) Builder - sends email to dev & user list stating that website X.X
> > RC1 is available for review at http://intermediate/foo/index.html
> > 4) Everyone interested clicks on the links reads the doc etc and
> > files jira issues against the site
> > 5) Repeat steps 1 - 4 until dev's are satisfied with the site
> > 6) Builder - push the site out to official project site
> >
> > This is not necessary but adds a bit of safety that the pushed site
> > is 'good'.
> >
> > If we had an automated link crawler we could automate that as part of
> > continuum and get an email right after a checkin breaks the site,
> > just another thought...
>
> I was thinking that we could automate the website (like we were trying
> to do with forrest.) This way corrections to documentation and new
> announcements get pushed out right away.
>
> Before we cutover to the mavenized site, an extensive review is
> definitely in order. Also an automated link check would be nice as a
> minimum.
>
> > I like assembly.
>
> So noted. Bernd and I aren't wild about it but we're planning on
> keeping it for now while we get the actual build working. Then we can
> revisit naming. He is also looking forward to continuum which I know
> you will be happy about.
>
> Sean
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
I guess this change makes sense now that I'm suggesting we split the
examples by tomahawk and sandbox.
Should I go ahead and start the move?
Sean
On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> The next round
> tomahawk should not build sandbox if I only make changes in tomahawk
>
> core (org.apache.myfaces)
> [This has a own release cycle]
> ====
> myfaces/core/trunk/pom.xml
> myfaces/core/trunk/myfaces-api/pom.xml
> myfaces/core/trunk/myfaces-impl/pom.xml
> myfaces/core/trunk/assembly/pom.xml
>
> <modules>
> <module>myfaces-api</module>
> <module>myfaces-impl</module>
> <module>assembly</module>
> <modules>
>
>
> commons (org.apache.myfaces)
> [This has a own release cycle]
> =======
> myfaces/commons/trunk/pom.xml
> myfaces/commons/trunk/src/main
> myfaces/commons/trunk/src/test
> myfaces/commons/trunk/src/site
> [myfaces/commons/assembly/pom.xml]
>
> NOTE: own assembly not really needed
> if released as part of the assembly of core and tomahawk
>
>
> tomahawk & sandbox
> (org.apache.myfaces.tomahawk or org.apache.myfaces)
> [This has a own release cycle]
> [Sandbox is not released only in nightly build]
> =======
> myfaces/tomahawk/trunk/pom.xml
> myfaces/tomahawk/trunk/src/site
> myfaces/tomahawk/trunk/tomahawk/pom.xml
> myfaces/tomahawk/trunk/tomahawk/src/main
> myfaces/tomahawk/trunk/tomahawk/src/test
> myfaces/tomahawk/trunk/tomahawk/src/site
> myfaces/tomahawk/trunk/tomahawk/example/pom.xml
> myfaces/tomahawk/trunk/sandbox/pom.xml
> myfaces/tomahawk/trunk/sandbox/src/main
> myfaces/tomahawk/trunk/sandbox/src/test
> myfaces/tomahawk/trunk/sandbox/src/site
> myfaces/tomahawk/trunk/sandbox/example/pom.xml
> myfaces/tomahawk/trunk/assembly/pom.xml
>
> NOTE: If tomahawk has a different groupid the pom is not inherited
> Maybe we can start which the same groupid, if it makes sense we can
> change it in a future version. (When the tomahawk pom is to different)
> NOTE: You should be able to build tomahawk without sandbox. Maybe the
> examples should move to tomahawk/trunk/examples/tomahawk and
> tomahawk/trunk/examples/sandbox for the same reason.
>
> tools (org.apache.myfaces)
> [no assembly but release on a maven repository]
> =====
> myfaces/tools/trunk/pom.xml
> myfaces/tools/trunk/myfaces-archetype-plugin/pom.xml
> myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm
>
> NOTE: The myfaces-archetype-plugin is an archetype-plugin for maven
> currently in the test repository.
>
> site (org.apache.myfaces)
> [never released only for publishing the main site and the content of the
> main site]
> =====
> myfaces/site/trunk/pom.xml
>
> NOTE: The main site can be part of core but the site is for everything
> not just for core
>
>
> Process for updating the site and publishing the nightly builds and the
> snapshots:
> =======
> This is done by special task from the continuum server or by some
> chron scripts invoked on the myfaces.zone.apache.org server?
>
> The idea is:
> We call some maven goals on some poms.
> mvn site:deploy in the site trunk for the main site
> mvn site:deploy in the core, commons and tomahawk trunk
>
> NOTE: The links between the the top level site and the subprojects are
> added manually in the site.xml. The svn version of the site plugin is
> reactor aware(Then not all links between the subprojects must defined).
>
> mvn deploy:deploy on all trunks for deploying all artifacts to the
> snapshot repository
>
> mvn assembly:assembly for the nightly build on core and tomahawk
>
> NOTE: A release need some more steps, but maven has a plugin for this
> and a best practice.
>
> TODO define a snapshot repository
> TODO define all artifactids
> TODO find a better name for assembly (dist|build|bin)?
> TODO use the myfaces solaris zone for publish the site, nightly build,
> continuum..
> TODO setup continuum
> TODO define the process for updating the site and nightly build
>
> Best Regards
>
> Bernd
>
>
> --
> Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
> Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
> phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
> Agreed - I have been in and out of the deve lists for the last 6
> weeks or so and have not had a chance to follow the discussion on
> commons and how we package it so that tomahawk can run on the RI. Is
> the idea that tomahawk would have two assemblies, one for running in
> the RI and one for MyFaces?
myfaces-commons.jar is just the stuff that was in the former 'share'
module (code that is shared between tomahawk and impl.) The jar is
now to be released independently of the two projects and both the
myfacaces implementation distro and the tomahawk distro will contain a
version of myfaces-commons.jar. Most likely each release of *either*
the implementation or tomahawk will involve a new release of commons.
> This is fantastic! Perhaps we could donate it to the mojo project on
> codehaus? That project seems to get lots of exposure and exposure
> never hurts :-)
A worthy idea. We haven't gotten around to the snapshot repository
and a few other things like this yet but Bruno has written a plugin.
We just need to move it out of the test svn repo to its new home.
> Do we want to do some QA on the site before pushing it out? Something
> like a nightly build of the site that someone could point a link
> crawler at? Just a thought. We had a somewhat lengthy discussion on
> this topic on the WADI incubation list but I don't think that list is
> archived yet. Here is the jest of what we came up with for WADI
> (Builder is the site builder);
>
> 1) Builder - builds site with mvn site and does an initial sanity check
> 2) Builder - once satisfied that the build is not a waste of anyone
> else's time pushes the site to an intermediate server
> 3) Builder - sends email to dev & user list stating that website X.X
> RC1 is available for review at http://intermediate/foo/index.html
> 4) Everyone interested clicks on the links reads the doc etc and
> files jira issues against the site
> 5) Repeat steps 1 - 4 until dev's are satisfied with the site
> 6) Builder - push the site out to official project site
>
> This is not necessary but adds a bit of safety that the pushed site
> is 'good'.
>
> If we had an automated link crawler we could automate that as part of
> continuum and get an email right after a checkin breaks the site,
> just another thought...
I was thinking that we could automate the website (like we were trying
to do with forrest.) This way corrections to documentation and new
announcements get pushed out right away.
Before we cutover to the mavenized site, an extensive review is
definitely in order. Also an automated link check would be nice as a
minimum.
> I like assembly.
So noted. Bernd and I aren't wild about it but we're planning on
keeping it for now while we get the actual build working. Then we can
revisit naming. He is also looking forward to continuum which I know
you will be happy about.
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Bill Dudney <bd...@mac.com>.
HI All,
Comments inline
On Jan 7, 2006, at 5:39 AM, Bernd Bohmann wrote:
> The next round
> tomahawk should not build sandbox if I only make changes in tomahawk
>
> core (org.apache.myfaces)
> [This has a own release cycle]
> ====
> myfaces/core/trunk/pom.xml
> myfaces/core/trunk/myfaces-api/pom.xml
> myfaces/core/trunk/myfaces-impl/pom.xml
> myfaces/core/trunk/assembly/pom.xml
>
> <modules>
> <module>myfaces-api</module>
> <module>myfaces-impl</module>
> <module>assembly</module>
> <modules>
>
>
> commons (org.apache.myfaces)
> [This has a own release cycle]
> =======
> myfaces/commons/trunk/pom.xml
> myfaces/commons/trunk/src/main
> myfaces/commons/trunk/src/test
> myfaces/commons/trunk/src/site
> [myfaces/commons/assembly/pom.xml]
>
> NOTE: own assembly not really needed
> if released as part of the assembly of core and tomahawk
>
>
> tomahawk & sandbox
> (org.apache.myfaces.tomahawk or org.apache.myfaces)
> [This has a own release cycle]
> [Sandbox is not released only in nightly build]
> =======
> myfaces/tomahawk/trunk/pom.xml
> myfaces/tomahawk/trunk/src/site
> myfaces/tomahawk/trunk/tomahawk/pom.xml
> myfaces/tomahawk/trunk/tomahawk/src/main
> myfaces/tomahawk/trunk/tomahawk/src/test
> myfaces/tomahawk/trunk/tomahawk/src/site
> myfaces/tomahawk/trunk/tomahawk/example/pom.xml
> myfaces/tomahawk/trunk/sandbox/pom.xml
> myfaces/tomahawk/trunk/sandbox/src/main
> myfaces/tomahawk/trunk/sandbox/src/test
> myfaces/tomahawk/trunk/sandbox/src/site
> myfaces/tomahawk/trunk/sandbox/example/pom.xml
> myfaces/tomahawk/trunk/assembly/pom.xml
>
> NOTE: If tomahawk has a different groupid the pom is not inherited
> Maybe we can start which the same groupid, if it makes sense we can
> change it in a future version. (When the tomahawk pom is to different)
I like this.
> NOTE: You should be able to build tomahawk without sandbox. Maybe
> the examples should move to tomahawk/trunk/examples/tomahawk and
> tomahawk/trunk/examples/sandbox for the same reason.
>
Agreed - I have been in and out of the deve lists for the last 6
weeks or so and have not had a chance to follow the discussion on
commons and how we package it so that tomahawk can run on the RI. Is
the idea that tomahawk would have two assemblies, one for running in
the RI and one for MyFaces?
> tools (org.apache.myfaces)
> [no assembly but release on a maven repository]
> =====
> myfaces/tools/trunk/pom.xml
> myfaces/tools/trunk/myfaces-archetype-plugin/pom.xml
> myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm
>
> NOTE: The myfaces-archetype-plugin is an archetype-plugin for maven
> currently in the test repository.
>
This is fantastic! Perhaps we could donate it to the mojo project on
codehaus? That project seems to get lots of exposure and exposure
never hurts :-)
> site (org.apache.myfaces)
> [never released only for publishing the main site and the content
> of the
> main site]
> =====
> myfaces/site/trunk/pom.xml
>
> NOTE: The main site can be part of core but the site is for everything
> not just for core
>
>
> Process for updating the site and publishing the nightly builds and
> the snapshots:
> =======
> This is done by special task from the continuum server or by some
> chron scripts invoked on the myfaces.zone.apache.org server?
>
> The idea is:
> We call some maven goals on some poms.
> mvn site:deploy in the site trunk for the main site
Do we want to do some QA on the site before pushing it out? Something
like a nightly build of the site that someone could point a link
crawler at? Just a thought. We had a somewhat lengthy discussion on
this topic on the WADI incubation list but I don't think that list is
archived yet. Here is the jest of what we came up with for WADI
(Builder is the site builder);
1) Builder - builds site with mvn site and does an initial sanity check
2) Builder - once satisfied that the build is not a waste of anyone
else's time pushes the site to an intermediate server
3) Builder - sends email to dev & user list stating that website X.X
RC1 is available for review at http://intermediate/foo/index.html
4) Everyone interested clicks on the links reads the doc etc and
files jira issues against the site
5) Repeat steps 1 - 4 until dev's are satisfied with the site
6) Builder - push the site out to official project site
This is not necessary but adds a bit of safety that the pushed site
is 'good'.
If we had an automated link crawler we could automate that as part of
continuum and get an email right after a checkin breaks the site,
just another thought...
> mvn site:deploy in the core, commons and tomahawk trunk
>
> NOTE: The links between the the top level site and the subprojects are
> added manually in the site.xml. The svn version of the site plugin is
> reactor aware(Then not all links between the subprojects must
> defined).
>
> mvn deploy:deploy on all trunks for deploying all artifacts to the
> snapshot repository
>
> mvn assembly:assembly for the nightly build on core and tomahawk
>
> NOTE: A release need some more steps, but maven has a plugin for this
> and a best practice.
>
> TODO define a snapshot repository
Don't we have space on apache somewhere - I know the incubator
projects have space to do this kind of thing I'd be happy to look
into it.
> TODO define all artifactids
> TODO find a better name for assembly (dist|build|bin)?
I like assembly.
> TODO use the myfaces solaris zone for publish the site, nightly
> build, continuum..
> TODO setup continuum
> TODO define the process for updating the site and nightly build
>
> Best Regards
>
> Bernd
>
>
> --
> Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
> Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
> phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
The next round
tomahawk should not build sandbox if I only make changes in tomahawk
core (org.apache.myfaces)
[This has a own release cycle]
====
myfaces/core/trunk/pom.xml
myfaces/core/trunk/myfaces-api/pom.xml
myfaces/core/trunk/myfaces-impl/pom.xml
myfaces/core/trunk/assembly/pom.xml
<modules>
<module>myfaces-api</module>
<module>myfaces-impl</module>
<module>assembly</module>
<modules>
commons (org.apache.myfaces)
[This has a own release cycle]
=======
myfaces/commons/trunk/pom.xml
myfaces/commons/trunk/src/main
myfaces/commons/trunk/src/test
myfaces/commons/trunk/src/site
[myfaces/commons/assembly/pom.xml]
NOTE: own assembly not really needed
if released as part of the assembly of core and tomahawk
tomahawk & sandbox
(org.apache.myfaces.tomahawk or org.apache.myfaces)
[This has a own release cycle]
[Sandbox is not released only in nightly build]
=======
myfaces/tomahawk/trunk/pom.xml
myfaces/tomahawk/trunk/src/site
myfaces/tomahawk/trunk/tomahawk/pom.xml
myfaces/tomahawk/trunk/tomahawk/src/main
myfaces/tomahawk/trunk/tomahawk/src/test
myfaces/tomahawk/trunk/tomahawk/src/site
myfaces/tomahawk/trunk/tomahawk/example/pom.xml
myfaces/tomahawk/trunk/sandbox/pom.xml
myfaces/tomahawk/trunk/sandbox/src/main
myfaces/tomahawk/trunk/sandbox/src/test
myfaces/tomahawk/trunk/sandbox/src/site
myfaces/tomahawk/trunk/sandbox/example/pom.xml
myfaces/tomahawk/trunk/assembly/pom.xml
NOTE: If tomahawk has a different groupid the pom is not inherited
Maybe we can start which the same groupid, if it makes sense we can
change it in a future version. (When the tomahawk pom is to different)
NOTE: You should be able to build tomahawk without sandbox. Maybe the
examples should move to tomahawk/trunk/examples/tomahawk and
tomahawk/trunk/examples/sandbox for the same reason.
tools (org.apache.myfaces)
[no assembly but release on a maven repository]
=====
myfaces/tools/trunk/pom.xml
myfaces/tools/trunk/myfaces-archetype-plugin/pom.xml
myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm
NOTE: The myfaces-archetype-plugin is an archetype-plugin for maven
currently in the test repository.
site (org.apache.myfaces)
[never released only for publishing the main site and the content of the
main site]
=====
myfaces/site/trunk/pom.xml
NOTE: The main site can be part of core but the site is for everything
not just for core
Process for updating the site and publishing the nightly builds and the
snapshots:
=======
This is done by special task from the continuum server or by some
chron scripts invoked on the myfaces.zone.apache.org server?
The idea is:
We call some maven goals on some poms.
mvn site:deploy in the site trunk for the main site
mvn site:deploy in the core, commons and tomahawk trunk
NOTE: The links between the the top level site and the subprojects are
added manually in the site.xml. The svn version of the site plugin is
reactor aware(Then not all links between the subprojects must defined).
mvn deploy:deploy on all trunks for deploying all artifacts to the
snapshot repository
mvn assembly:assembly for the nightly build on core and tomahawk
NOTE: A release need some more steps, but maven has a plugin for this
and a best practice.
TODO define a snapshot repository
TODO define all artifactids
TODO find a better name for assembly (dist|build|bin)?
TODO use the myfaces solaris zone for publish the site, nightly build,
continuum..
TODO setup continuum
TODO define the process for updating the site and nightly build
Best Regards
Bernd
--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
The next round
core (org.apache.myfaces)
[This has a own release cycle]
====
myfaces/core/trunk/pom.xml
myfaces/core/trunk/myfaces-api/pom.xml
myfaces/core/trunk/myfaces-impl/pom.xml
myfaces/core/trunk/assembly/pom.xml
<modules>
<module>myfaces-api</module>
<module>myfaces-impl</module>
<module>assembly</module>
<modules>
commons (org.apache.myfaces)
[This has a own release cycle]
=======
myfaces/commons/trunk/pom.xml
myfaces/commons/trunk/src/main
myfaces/commons/trunk/src/test
myfaces/commons/trunk/src/site
[myfaces/commons/assembly/pom.xml]
NOTE: own assembly not really needed
if released as part of the assembly of core and tomahawk
tomahawk & sandbox
(org.apache.myfaces.tomahawk or org.apache.myfaces)
[This has a own release cycle]
[Sandbox is not released only in nightly build]
=======
myfaces/tomahawk/trunk/pom.xml
myfaces/tomahawk/trunk/src/main
myfaces/tomahawk/trunk/src/test
myfaces/tomahawk/trunk/src/site
myfaces/tomahawk/trunk/example/pom.xml
myfaces/tomahawk/trunk/sandbox/pom.xml
myfaces/tomahawk/trunk/sandbox/src/main
myfaces/tomahawk/trunk/sandbox/src/test
myfaces/tomahawk/trunk/sandbox/src/site
myfaces/tomahawk/trunk/sandbox/example/pom.xml
myfaces/tomahawk/trunk/assembly/pom.xml
NOTE: If tomahawk has a different groupid the pom is not inherited
Maybe we can start which the same groupid, if it makes sense we can
change it in a future version. (When the tomahawk pom is to different)
tools (org.apache.myfaces)
[no assembly but release on a maven repository]
=====
myfaces/tools/trunk/pom.xml
myfaces/tools/trunk/myfaces-archetype-plugin/pom.xml
myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm
NOTE: The myfaces-archetype-plugin is an archetype-plugin for maven
currently in the test repository.
site (org.apache.myfaces)
[never released only for publishing the main site and the content of the
main site]
=====
myfaces/site/trunk/pom.xml
NOTE: The main site can be part of core but the site is for everything
not just for core
Process for updating the site and publishing the nightly builds and the
snapshots:
=======
This is done by special task from the continuum server or by some
chron scripts invoked on the myfaces.zone.apache.org server?
The idea is:
We call some maven goals on some poms.
mvn site:deploy in the site trunk for the main site
mvn site:deploy in the core, commons and tomahawk trunk
NOTE: The links between the the top level site and the subprojects are
added manually in the site.xml. The svn version of the site plugin is
reactor aware(Then not all links between the subprojects must defined).
mvn deploy:deploy on all trunks for deploying all artifacts to the
snapshot repository
mvn assembly:assembly for the nightly build on core and tomahawk
NOTE: A release need some more steps, but maven has a plugin for this
and a best practice.
TODO find a better name for assembly (dist|build|bin)?
TODO use the myfaces solaris zone for publish the site, nightly build,
continuum..
TODO setup continuum
TODO define a snapshot repository
TODO define the process for updating the site and nightly build
Best Regards
Bernd
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
Looks pretty good. One minor change and a few questions.
@Martin: Any comments on this before we go ahead? (We will keep your
resource structure for now and try to find a solution for that later.)
> The next try:
>
> core (org.apache.myfaces)
> [This has a own release cycle]
> ====
> myfaces/core/trunk/pom.xml
> myfaces/core/trunk/myfaces-api/pom.xml
> myfaces/core/trunk/myfaces-impl/pom.xml
> myfaces/core/trunk/assembly/pom.xml
>
> <modules>
> <module>myfaces-api</module>
> <module>myfaces-impl</module>
> <module>assembly</module>
> <modules>
>
>
> commons (org.apache.myfaces)
> [This has a own release cycle]
> =======
> myfaces/commons/trunk/pom.xml
> myfaces/commons/trunk/src/main
> myfaces/commons/trunk/src/test
> myfaces/commons/trunk/src/site
> [myfaces/commons/assembly/pom.xml]
> NOTE: own assembly not really needed
> if released as part of the assembly of core and tomahawk
OK. Now I understand why you skipped assembly for this one.
>
> tomahawk & sandbox
> (org.apache.myfaces.tomahawk or org.apache.myfaces)
> [This has a own release cycle]
> [Sandbox is not released only in nightly build]
> =======
> myfaces/tomahawk/trunk/pom.xml
> myfaces/tomahawk/trunk/src/main
> myfaces/tomahawk/trunk/src/test
> myfaces/tomahawk/trunk/src/site
> myfaces/tomahawk/trunk/example/pom.xml
> myfaces/tomahawk/trunk/sandbox/pom.xml
> myfaces/tomahawk/trunk/sandbox/src/main
> myfaces/tomahawk/trunk/sandbox/src/test
> myfaces/tomahawk/trunk/sandbox/src/site
> myfaces/tomahawk/trunk/assembly/pom.xml
>
> NOTE: If tomahawk has a different groupid the pom is not inherited
> Maybe we can start which the same groupid, if it make sense we can
> change it in a future version. (The tomahawk pom is to different)
One more change ...
myfaces/tomahawk/trunk/sandbox/example <-- add this
Sandbox examples will depend on sandbox components and the
sandbox.jar. So they should probably be broken out separately.
> tools (org.apache.myfaces)
> [no assembly but release on a maven repository]
> =====
> myfaces/tools/trunk/pom.xml
> myfaces/tools/trunk/maven-myfaces-plugin/pom.xml
> myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm
>
> NOTE: The maven-myfaces-plugin is an archtype-plugin for maven currently
> in the test repository.
Oh yes Bruno's archtype plugin. Yes that should go there.
> site (org.apache.myfaces)
> [never released only for publishing the main site and the content of the
> main site]
> =====
> myfaces/site/trunk/pom.xml
> NOTE: The main site can be part of core
It could be part of core but I think your initial idea (as its own top
level) is better. The site is for everything (not just core.)
>
> Process for updateing the site and publishing the nightly build and the
> snapshots:
> This is done by spezial task from the continuum server or by some
> scripts invoked on the myfaces.zone.apache.org server?
I was thinking chron script on the zone.
> The idea is: We call some maven goals on some poms.
> mvn site:deploy in the site trunk for the main site
> mvn site:deploy in the core, commons and tomahawk trunk
Sounds good. The one thing is that I would like links in the top
level site for the module sites (and also in the reverse direction.)
Do we just add those manually to the nav contents of each of the
sites? Is there a way to do this in Maven?
> mvn deploy:deploy on all trunks for the shapshots
And this will make the snapshots available to our own projects as well
as those of our users right? Sounds good.
> mvn assembly:assembly for the nightly build on core and tomahawk
Right. And maybe also for the official release?
> NOTE: I don't expect one spezial pom for this.
I guess you're right. There isn't anything in Maven that will pull it
all together for you.
> TODO find a better name for assembly
We can try ;-) Build is already taken. Maybe publish?
> TODO setup solaris zone
Its been setup. Nothing has been done with it yet. Once we get the
builds working that will be the next step.
> TODO setup continuum
> TODO define a snapshot repository
> TODO define the process for updating the site and nightly buid
Yes. This looks great Bernd. I like what we are settling on.
>
> Best Regards
>
> Bernd
>
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
The next try:
core (org.apache.myfaces)
[This has a own release cycle]
====
myfaces/core/trunk/pom.xml
myfaces/core/trunk/myfaces-api/pom.xml
myfaces/core/trunk/myfaces-impl/pom.xml
myfaces/core/trunk/assembly/pom.xml
<modules>
<module>myfaces-api</module>
<module>myfaces-impl</module>
<module>assembly</module>
<modules>
commons (org.apache.myfaces)
[This has a own release cycle]
=======
myfaces/commons/trunk/pom.xml
myfaces/commons/trunk/src/main
myfaces/commons/trunk/src/test
myfaces/commons/trunk/src/site
[myfaces/commons/assembly/pom.xml]
NOTE: own assembly not really needed
if released as part of the assembly of core and tomahawk
tomahawk & sandbox
(org.apache.myfaces.tomahawk or org.apache.myfaces)
[This has a own release cycle]
[Sandbox is not released only in nightly build]
=======
myfaces/tomahawk/trunk/pom.xml
myfaces/tomahawk/trunk/src/main
myfaces/tomahawk/trunk/src/test
myfaces/tomahawk/trunk/src/site
myfaces/tomahawk/trunk/example/pom.xml
myfaces/tomahawk/trunk/sandbox/pom.xml
myfaces/tomahawk/trunk/sandbox/src/main
myfaces/tomahawk/trunk/sandbox/src/test
myfaces/tomahawk/trunk/sandbox/src/site
myfaces/tomahawk/trunk/assembly/pom.xml
NOTE: If tomahawk has a different groupid the pom is not inherited
Maybe we can start which the same groupid, if it make sense we can
change it in a future version. (The tomahawk pom is to different)
tools (org.apache.myfaces)
[no assembly but release on a maven repository]
=====
myfaces/tools/trunk/pom.xml
myfaces/tools/trunk/maven-myfaces-plugin/pom.xml
myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xm
NOTE: The maven-myfaces-plugin is an archtype-plugin for maven currently
in the test repository.
site (org.apache.myfaces)
[never released only for publishing the main site and the content of the
main site]
=====
myfaces/site/trunk/pom.xml
NOTE: The main site can be part of core
Process for updateing the site and publishing the nightly build and the
snapshots:
This is done by spezial task from the continuum server or by some
scripts invoked on the myfaces.zone.apache.org server?
The idea is: We call some maven goals on some poms.
mvn site:deploy in the site trunk for the main site
mvn site:deploy in the core, commons and tomahawk trunk
mvn deploy:deploy on all trunks for the shapshots
mvn assembly:assembly for the nightly build on core and tomahawk
NOTE: I don't expect one spezial pom for this.
TODO find a better name for assembly
TODO setup solaris zone
TODO setup continuum
TODO define a snapshot repository
TODO define the process for updating the site and nightly buid
Best Regards
Bernd
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
Bernd,
I think we're close to agreement. I'm going to hold off on the reorg
until Saturday. There are enough issues that need to be addressed to
make it worth waiting at least one more day. I have a few
questions/points for you inline.
On 1/5/06, Bernd Bohmann <be...@atanion.com> wrote:
> I try a summary:
>
> core (org.apache.myfaces)
> [This has a own release cycle]
> ====
> myfaces/core/trunk/pom.xml
> myfaces/core/trunk/myfaces-api/pom.xml
> myfaces/core/trunk/myfaces-impl/pom.xml
> myfaces/core/trunk/assembly/pom.xml
>
> commons (org.apache.myfaces)
> [This has a own release cycle]
> =======
> myfaces/commons/trunk/pom.xml
We should also have myfaces/commons/assembly/pom.xml right?
> tomahawk & sandbox (org.apache.myfaces.tomahawk)
> [This has a own release cycle]
> [Sandbox is not released only in nightly build]
> =======
> myfaces/tomahawk/trunk/pom.xml
> myfaces/tomahawk/trunk/example/pom.xml
> myfaces/tomahawk/trunk/sandbox/pom.xml
> myfaces/tomahawk/trunk/assembly/pom.xml
Let me make sure I understand you. Under myfaces/tomahawk/trunk we
would have the usual src/main/java src/main, src/test, src/site, etc.
all for tomahawk. So in more detail you would have
myfaces/tomahawk/trunk/pom.xml
myfaces/tomahawk/trunk/src/main
myfaces/tomahawk/trunk/src/test
myfaces/tomahawk/trunk/src/site
myfaces/tomahawk/trunk/example/pom.xml
myfaces/tomahawk/trunk/sandbox/pom.xml
myfaces/tomahawk/trunk/sandbox/src/main
myfaces/tomahawk/trunk/sandbox/src/test
myfaces/tomahawk/trunk/sandbox/src/site
myfaces/tomahawk/trunk/assembly/pom.xml
Is this what you mean?
> tools (org.apache.myfaces)
> [no assembly but release on a maven repository]
> =====
> myfaces/tools/trunk/pom.xml
> myfaces/tools/trunk/maven-myfaces-plugin/pom.xml
> myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xml
What is maven-myfaces-plugin? Is this some future plugin TBD or is
this something specific you had in mind? Just curious. I think for
now we can just reserve myfaces/tools for future use and discuss that
later (once the basic build is working.)
> site (org.apache.myfaces)
> [maybe never released only for the main site]
> =====
> myfaces/site/trunk/pom.xml
Definitely not released since its just the website. This would have
the top level website stuff (overview, etc.) Can we pull the enitre
website together in the myfaces/assembly/pom.xml? It would be nice if
we could use one pom for running assembly, publishing the nightlies
and updating the site.
> TODO find a better name for assembly
> TODO setup continuum
> TODO define a snapshot repository
+ 1
> NOTE: tomahawk has a different groupid the pom is not inherited
>
Why is this necessary to have a different group id. Earlier you
explained what happens if they are different but not why the *should*
be different.
> Bernd
>
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
I try a summary:
core (org.apache.myfaces)
[This has a own release cycle]
====
myfaces/core/trunk/pom.xml
myfaces/core/trunk/myfaces-api/pom.xml
myfaces/core/trunk/myfaces-impl/pom.xml
myfaces/core/trunk/assembly/pom.xml
commons (org.apache.myfaces)
[This has a own release cycle]
=======
myfaces/commons/trunk/pom.xml
tomahawk & sandbox (org.apache.myfaces.tomahawk)
[This has a own release cycle]
[Sandbox is not released only in nightly build]
=======
myfaces/tomahawk/trunk/pom.xml
myfaces/tomahawk/trunk/example/pom.xml
myfaces/tomahawk/trunk/sandbox/pom.xml
myfaces/tomahawk/trunk/assembly/pom.xml
tools (org.apache.myfaces)
[no assembly but release on a maven repository]
=====
myfaces/tools/trunk/pom.xml
myfaces/tools/trunk/maven-myfaces-plugin/pom.xml
myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xml
site (org.apache.myfaces)
[maybe never released only for the main site]
=====
myfaces/site/trunk/pom.xml
TODO find a better name for assembly
TODO setup continuum
TODO define a snapshot repository
NOTE: tomahawk has a different groupid the pom is not inherited
Is something missing?
Best Regards
Bernd
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
I understood that modules were called from the parent. I was trying
to understand the relationship in the other direction. It sounds like
it consults the parent POM and inherits its attributes but does *not*
build it. That's more of what I would expect ...
Sean
On 1/5/06, Bill Dudney <bd...@mac.com> wrote:
>
> On Jan 5, 2006, at 2:13 PM, Arvid Hülsebus wrote:
>
> > Sean Schofield wrote:
> >
> >> Does this mean that if you build the child, it asks the parent to
> >> build? If so, then that is interesting (not a problem - just
> >> unexpected.)
> >>
> > As far as I understand it Maven only builds "child" projects if the
> > POM includes a module entry for that "child". In general it applies
> > a goal on all included modules. These child modules won't even need
> > a parent entry. Maven just changes into the directory with name in
> > the module entry.
> >
> > The parent entry is more or less for inheriting common stuff. But
> > it won't instruct Maven to build the parent.
> >
>
> Sorry Sean, I missed that in my last response. My understanding and
> experiences mirrors Arvid's.
>
> TTFN,
>
> -bd-
>
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Bill Dudney <bd...@mac.com>.
On Jan 5, 2006, at 2:13 PM, Arvid Hülsebus wrote:
> Sean Schofield wrote:
>
>> Does this mean that if you build the child, it asks the parent to
>> build? If so, then that is interesting (not a problem - just
>> unexpected.)
>>
> As far as I understand it Maven only builds "child" projects if the
> POM includes a module entry for that "child". In general it applies
> a goal on all included modules. These child modules won't even need
> a parent entry. Maven just changes into the directory with name in
> the module entry.
>
> The parent entry is more or less for inheriting common stuff. But
> it won't instruct Maven to build the parent.
>
Sorry Sean, I missed that in my last response. My understanding and
experiences mirrors Arvid's.
TTFN,
-bd-
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Arvid Hülsebus <ar...@atanion.com>.
Sean Schofield wrote:
>Does this mean that if you build the child, it asks the parent to build? If so, then that is interesting (not a problem - just unexpected.)
>
>
As far as I understand it Maven only builds "child" projects if the POM
includes a module entry for that "child". In general it applies a goal
on all included modules. These child modules won't even need a parent
entry. Maven just changes into the directory with name in the module entry.
The parent entry is more or less for inheriting common stuff. But it
won't instruct Maven to build the parent.
Regards,
Arvid
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
> The argument for parent refs is to define many things at one place.
> The version is not really the reason, because it is defined in the
> parent ref.
> Without parent refs you have to define the
> <issueManagement>
> <ciManagement>
> <developers>
> <reports>
> ....
> in every pom.
Ok then we definitely want the parent ref! I thought that those were
inherited when you used <module>. I didn't realize you had to specify
that you were the child of a particular POM. Does this mean that if
you build the child, it asks the parent to build? If so, then that is
interesting (not a problem - just unexpected.)
> A legitimate question:
> Is the core pom a parent of the tomahawk pom, this depends on the
> differences of the poms. If tomahawk has a different groupId it can't be
> a child of core.
I would say tomahawk and core are independent of one another.
Actually all of the "top" level POMS would be independent of one
another. So you would have 3 separate group ids.
org.apache.myfaces.core
org.apache.myfaces.tomahawk
org.apache.myfaces.commons
What is the significance of the group id? I know that your repository
will have one folder for each but what else does it mean? Underneath
the group id folder is the version right? If each of these 3 can have
their own release cycle then I think we *must* have 3 group ids right?
> > commons
> > =======
> > myfaces/commons/trunk
>
> I think commons should have a parent ref to myfaces.
What do you mean by this?
> TODO find a better name for assembly
+1
> > maven-tools
> > =========
> >
> > custom maven plugins, etc.
>
> Not only maven tools. I would suggest myfaces-tools or myfaces-build-tools?
What else goes in here besides plugins?
> I think the experimental stuff should only released as a nighly build.
I'm ok with your suggestion but a while back there seemed to be
support for including it in tomahawk. I can't remember the arguments
off the top of my head. I will do an archive search ...
> and tobago is released :-)
Of course, we shouldn't forget tobago ;-) Its good to have you guys
on board. Your Maven experience is already coming in handy.
[snip]
> A continuum server updates automatically the myfaces snapshot repository.
> If an other developer perform an update of tomahawk, the next call of
> mvn fetch the new snapshot of commons into his local repository from the
> myfaces snapshot repository.
>
> TODO setup continuum
> TODO define the snapshot repository
OK I think I see what you mean. We can come back to your suggestion
later when we get the SVN stuff done. I was interested in continuum
before this explanation but now I am *very* interested. Bill Dudney
has also expressed interest and now that we have our zone we can do
this! First things first though. Lets get *re*organized and get the
POMs the way we want them.
Thanks for your excellent ideas ...
Sean
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Bill Dudney <bd...@mac.com>.
Hi Sean,
thanks for cross posting this stuff to the correct thread :-)
On Jan 5, 2006, at 1:43 PM, Sean Schofield wrote:
> @Bill: moving a snip of your comments to this thread ...
>
>> I'd like to see something like this;
>>
>> myfaces/pom.xml
>> myfaces/api/pom.xml
>> myfaces/commons/pom.xml
>> myfaces/examples/pom.xml
>> myfaces/impl/pom.xml
>> myfaces/sandbox/pom.xml
>> myfaces/tomahawk/pom.xml
>
> Is the point of the very top level POM for stuff that is common to
> 100% of the modules (like mailing list, jira, contributor lists, etc)?
>
Yes its to have all the common stuff in one place so you don't have
to change it over and over in all the modules.
Dependency versions is another big win IMO with a parent pom.
> Why not combine api and impl in their own "core" module? IMO there is
> no point in ever releasing those separately. Both constitute a JSF
> implementation.
Agreed, good point.
>
> One advantage to sandbox within tomahawk is we can cut down on the
> number of top level modules. Just throw the sandbox stuff into
> sandbox.jar and provide its own api docs. That stuff goes into the
> release bundle along with tomahawk.jar and we say "sandbox stuff is
> untested and subject too change or elimination."
>
+1 on combining sandbox and tomahawk. Are you thinking of making
tomahawk a mid level module that has 2 submodules?
myfaces/tomahawk/pom.xml => packaging = pom
myfaces/tomahawk/tomahawk
myfaces/tomahawk/sandbox
This is fine as it reduces the top level clutter. If you want to have
two products from a single module I'm not sure but I think it will
present problems from maven.
> I also think that the examples should go in tomahawk. They are
> basically examples of tomahawk in action and any time you add a new
> tomahawk component (or a significant feature to an existing component)
> you will want to update the examples. Also, I envision linking the
> tomahwk documentation to the examples on the website (now that we have
> our zone.) So I think the examples are tightly coupled to
> tomahawk/sandbox.
>
Agreed with this too, so we'd have something like this if I'm
understanding correctly;
myfaces/pom.xml => packaging = pom modules = (core, commons, tomahawk)
myfaces/core/pom.xml => packaging = pom modules = (impl, api)
myfaces/core/api/pom.xml => packaging = jar
myfaces/core/impl/pom.xml => packaging = jar
myfaces/commons/pom.xml => packaging = jar
myfaces/tomahawk/pom.xml => packaging = pom modules = (tomahawk,
sandbox, examples)
myfaces/tomahawk/tomahawk/pom.xml => packaging = jar
myfaces/tomahawk/sandbox/pom.xml => packaging = jar
myfaces/tomahawk/examples/pom.xml => packaging = war
This looks very good and much simpler, no externals etc. easy to
branch, tag etc.
We also need the publish thing to have an assembly as we have now,
although I've had less experience with making assemblies we have on
my other project the ability to do an 'mvn release' (or something
like that I'll have to look) and have the whole assembly pushed out
to the download site. I'll have to look at how we made that work, its
great stuff!
TTFN,
-bd-
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
@Bill: moving a snip of your comments to this thread ...
> I'd like to see something like this;
>
> myfaces/pom.xml
> myfaces/api/pom.xml
> myfaces/commons/pom.xml
> myfaces/examples/pom.xml
> myfaces/impl/pom.xml
> myfaces/sandbox/pom.xml
> myfaces/tomahawk/pom.xml
Is the point of the very top level POM for stuff that is common to
100% of the modules (like mailing list, jira, contributor lists, etc)?
Why not combine api and impl in their own "core" module? IMO there is
no point in ever releasing those separately. Both constitute a JSF
implementation.
One advantage to sandbox within tomahawk is we can cut down on the
number of top level modules. Just throw the sandbox stuff into
sandbox.jar and provide its own api docs. That stuff goes into the
release bundle along with tomahawk.jar and we say "sandbox stuff is
untested and subject too change or elimination."
I also think that the examples should go in tomahawk. They are
basically examples of tomahawk in action and any time you add a new
tomahawk component (or a significant feature to an existing component)
you will want to update the examples. Also, I envision linking the
tomahwk documentation to the examples on the website (now that we have
our zone.) So I think the examples are tightly coupled to
tomahawk/sandbox.
Thoughts on this? It would be *much* simpler to combine them....
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
+1 for me now too. I just wanted to understand what it gives you and
make sure we needed it.
On 1/5/06, Bill Dudney <bd...@mac.com> wrote:
> I really think we need the parent pom as Bernd points out below it
> keeps all the project level stuff in one place.
>
> TTFN,
>
> -bd-
> On Jan 5, 2006, at 12:21 PM, Bernd Bohmann wrote:
>
> >
> >
> > Sean Schofield schrieb:
> >
> >> Can you give me the arguments for parent refs? I still haven't heard
> >> a good reason. I'm not against the idea, I just don't know what they
> >> give you (other then a common version.) I think we can all agree
> >> that
> >> the externals are suboptimal. The question is what to do about it.
> > The argument for parent refs is to define many things at one place.
> > The version is not really the reason, because it is defined in the
> > parent ref.
> > Without parent refs you have to define the
> > <issueManagement>
> > <ciManagement>
> > <developers>
> > <reports>
> > ....
> > in every pom.
> >
> > A legitimate question:
> > Is the core pom a parent of the tomahawk pom, this depends on the
> > differences of the poms. If tomahawk has a different groupId it
> > can't be a child of core.
> >
> >> A good start. Here is a revised proposal based on Bernd's
> >> original one
> >> core
> >> ====
> >> myfaces/core/trunk/api
> >> myfaces/core/trunk/impl
> >> myfaces/core/trunk/assembly
> > Unfortunaly in maven style the directories should have the same
> > name as the artifact name (I don't like it)
> > pom in myfaces/core/trunk/
> > <modules>
> > <module>myfaces-api</module>
> > <module>myfaces-impl</module>
> > <module>assembly</module>
> > <modules>
> >
> > myfaces/core/trunk/myfaces-api
> > myfaces/core/trunk/myfaces-impl
> > myfaces/core/trunk/assembly (The assembly generates not really an
> > artifact)
> >
> > We should find a better name for assembly
> > some examples:
> > continuum > continuum-plexus-application
> > maven > maven-core
> >
> > maybe myfaces-core
> >
> >> commons
> >> =======
> >> myfaces/commons/trunk
> >
> > I think commons should have a parent ref to myfaces.
> >> tomahawk
> >> =======
> >> myfaces/tomahawk/trunk
> >> myfaces/tomahawk/trunk/example
> >> myfaces/tomahawk/trunk/assembly
> >> myfaces/sandbox/trunk
> >> myfaces/sandbox/trunk/example
> >> myfaces/sandbox/trunk/assembly
> > TODO find a better name for assembly
> >> maven-tools
> >> =========
> >> custom maven plugins, etc.
> >
> > Not only maven tools. I would suggest myfaces-tools or myfaces-
> > build-tools?
> >
> >
> >> NOTES:
> >> I took out the examples from core. The examples are 99% tomahawk
> >> related (other then the blank example which shows basic setup.) I
> >> think its easier to just leave examples out of core instead of having
> >> two copies, separate examples or svn externals.
> >> I merged sandbox and tomahawk together. A while back we decided to
> >> put the sandbox stuff in the tomahawk.jar. Since the sandbox is
> >> experimental it doesn't need its own release cycle. Also, stuff
> >> moves
> >> from sandbox to tomahawk so you will often update both anyways. The
> >> examples for tomahawk would be the current examples (minus
> >> sandbox). The sandbox examples would go under sandbox.
> >
> > I think the experimental stuff should only released as a nighly build.
> >
> >> Yes faster release cycles would be good. I suppose MyFaces commons
> >> will be released everytime *either* the core or tomahawk stuff is
> >> released. There are bound to be minor changes either time. That
> >> still saves us the trouble of branching, testing and merging the core
> >> stuff.
> >>
> > and tobago is released :-)
> >
> >> We had talked about a core project a while ago - but as an
> >> svn:external. I like this better. You are correct that branching
> >> and
> >> tagging will be much easier.
> > :-)
> >> I had thought about this. Is there a way to tell Maven "Use my local
> >> repository if it is newer then the maven repository?" Things could
> >> get kind of confusing if you are using your latest commons code in
> >> the
> >> IDE but Maven is using the last official release ..
> >
> > Yes, of cause.
> >
> > I will describe a possible release cycle of myfaces-commons, first.
> > Current development version 1.1.4-SNAPSHOT
> > Ready for a release create a branch 1.1.4 (maven-release-plugin)
> > and then change the version in trunk to 1.1.5-SNAPSHOT.
> >
> > On the branch you can apply last patches and finally perform a
> > release.
> >
> > If you have made changes in tomahawk that depends on myfaces-
> > commons-1.1.5-SNAPSHOT you must change the dependency in the
> > tomahawk pom. If you have made local changes in commons for
> > tomahawk, you only must install a new myfaces-commons-1.1.5-
> > SNAPSHOT in your local repository with mvn install(and change the
> > dependeny to 1.1.5-SNAPSHOT).
> >
> > After you are finished you have to commit your changes in common
> > and tomahawk.
> >
> > A continuum server updates automatically the myfaces snapshot
> > repository.
> > If an other developer perform an update of tomahawk, the next call
> > of mvn fetch the new snapshot of commons into his local repository
> > from the myfaces snapshot repository.
> >
> > TODO setup continuum
> > TODO define the snapshot repository
> >
> >
> >
> >> Sean
> > Regards
> >
> > Bernd
>
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Bill Dudney <bd...@mac.com>.
I really think we need the parent pom as Bernd points out below it
keeps all the project level stuff in one place.
TTFN,
-bd-
On Jan 5, 2006, at 12:21 PM, Bernd Bohmann wrote:
>
>
> Sean Schofield schrieb:
>
>> Can you give me the arguments for parent refs? I still haven't heard
>> a good reason. I'm not against the idea, I just don't know what they
>> give you (other then a common version.) I think we can all agree
>> that
>> the externals are suboptimal. The question is what to do about it.
> The argument for parent refs is to define many things at one place.
> The version is not really the reason, because it is defined in the
> parent ref.
> Without parent refs you have to define the
> <issueManagement>
> <ciManagement>
> <developers>
> <reports>
> ....
> in every pom.
>
> A legitimate question:
> Is the core pom a parent of the tomahawk pom, this depends on the
> differences of the poms. If tomahawk has a different groupId it
> can't be a child of core.
>
>> A good start. Here is a revised proposal based on Bernd's
>> original one
>> core
>> ====
>> myfaces/core/trunk/api
>> myfaces/core/trunk/impl
>> myfaces/core/trunk/assembly
> Unfortunaly in maven style the directories should have the same
> name as the artifact name (I don't like it)
> pom in myfaces/core/trunk/
> <modules>
> <module>myfaces-api</module>
> <module>myfaces-impl</module>
> <module>assembly</module>
> <modules>
>
> myfaces/core/trunk/myfaces-api
> myfaces/core/trunk/myfaces-impl
> myfaces/core/trunk/assembly (The assembly generates not really an
> artifact)
>
> We should find a better name for assembly
> some examples:
> continuum > continuum-plexus-application
> maven > maven-core
>
> maybe myfaces-core
>
>> commons
>> =======
>> myfaces/commons/trunk
>
> I think commons should have a parent ref to myfaces.
>> tomahawk
>> =======
>> myfaces/tomahawk/trunk
>> myfaces/tomahawk/trunk/example
>> myfaces/tomahawk/trunk/assembly
>> myfaces/sandbox/trunk
>> myfaces/sandbox/trunk/example
>> myfaces/sandbox/trunk/assembly
> TODO find a better name for assembly
>> maven-tools
>> =========
>> custom maven plugins, etc.
>
> Not only maven tools. I would suggest myfaces-tools or myfaces-
> build-tools?
>
>
>> NOTES:
>> I took out the examples from core. The examples are 99% tomahawk
>> related (other then the blank example which shows basic setup.) I
>> think its easier to just leave examples out of core instead of having
>> two copies, separate examples or svn externals.
>> I merged sandbox and tomahawk together. A while back we decided to
>> put the sandbox stuff in the tomahawk.jar. Since the sandbox is
>> experimental it doesn't need its own release cycle. Also, stuff
>> moves
>> from sandbox to tomahawk so you will often update both anyways. The
>> examples for tomahawk would be the current examples (minus
>> sandbox). The sandbox examples would go under sandbox.
>
> I think the experimental stuff should only released as a nighly build.
>
>> Yes faster release cycles would be good. I suppose MyFaces commons
>> will be released everytime *either* the core or tomahawk stuff is
>> released. There are bound to be minor changes either time. That
>> still saves us the trouble of branching, testing and merging the core
>> stuff.
>>
> and tobago is released :-)
>
>> We had talked about a core project a while ago - but as an
>> svn:external. I like this better. You are correct that branching
>> and
>> tagging will be much easier.
> :-)
>> I had thought about this. Is there a way to tell Maven "Use my local
>> repository if it is newer then the maven repository?" Things could
>> get kind of confusing if you are using your latest commons code in
>> the
>> IDE but Maven is using the last official release ..
>
> Yes, of cause.
>
> I will describe a possible release cycle of myfaces-commons, first.
> Current development version 1.1.4-SNAPSHOT
> Ready for a release create a branch 1.1.4 (maven-release-plugin)
> and then change the version in trunk to 1.1.5-SNAPSHOT.
>
> On the branch you can apply last patches and finally perform a
> release.
>
> If you have made changes in tomahawk that depends on myfaces-
> commons-1.1.5-SNAPSHOT you must change the dependency in the
> tomahawk pom. If you have made local changes in commons for
> tomahawk, you only must install a new myfaces-commons-1.1.5-
> SNAPSHOT in your local repository with mvn install(and change the
> dependeny to 1.1.5-SNAPSHOT).
>
> After you are finished you have to commit your changes in common
> and tomahawk.
>
> A continuum server updates automatically the myfaces snapshot
> repository.
> If an other developer perform an update of tomahawk, the next call
> of mvn fetch the new snapshot of commons into his local repository
> from the myfaces snapshot repository.
>
> TODO setup continuum
> TODO define the snapshot repository
>
>
>
>> Sean
> Regards
>
> Bernd
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
Sean Schofield schrieb:
> Can you give me the arguments for parent refs? I still haven't heard
> a good reason. I'm not against the idea, I just don't know what they
> give you (other then a common version.) I think we can all agree that
> the externals are suboptimal. The question is what to do about it.
>
The argument for parent refs is to define many things at one place.
The version is not really the reason, because it is defined in the
parent ref.
Without parent refs you have to define the
<issueManagement>
<ciManagement>
<developers>
<reports>
....
in every pom.
A legitimate question:
Is the core pom a parent of the tomahawk pom, this depends on the
differences of the poms. If tomahawk has a different groupId it can't be
a child of core.
> A good start. Here is a revised proposal based on Bernd's original one
>
> core
> ====
> myfaces/core/trunk/api
> myfaces/core/trunk/impl
> myfaces/core/trunk/assembly
>
Unfortunaly in maven style the directories should have the same name as
the artifact name (I don't like it)
pom in myfaces/core/trunk/
<modules>
<module>myfaces-api</module>
<module>myfaces-impl</module>
<module>assembly</module>
<modules>
myfaces/core/trunk/myfaces-api
myfaces/core/trunk/myfaces-impl
myfaces/core/trunk/assembly (The assembly generates not really an artifact)
We should find a better name for assembly
some examples:
continuum > continuum-plexus-application
maven > maven-core
maybe myfaces-core
> commons
> =======
> myfaces/commons/trunk
I think commons should have a parent ref to myfaces.
>
> tomahawk
> =======
>
> myfaces/tomahawk/trunk
> myfaces/tomahawk/trunk/example
> myfaces/tomahawk/trunk/assembly
> myfaces/sandbox/trunk
> myfaces/sandbox/trunk/example
> myfaces/sandbox/trunk/assembly
>
TODO find a better name for assembly
> maven-tools
> =========
>
> custom maven plugins, etc.
Not only maven tools. I would suggest myfaces-tools or myfaces-build-tools?
>
> NOTES:
>
> I took out the examples from core. The examples are 99% tomahawk
> related (other then the blank example which shows basic setup.) I
> think its easier to just leave examples out of core instead of having
> two copies, separate examples or svn externals.
>
> I merged sandbox and tomahawk together. A while back we decided to
> put the sandbox stuff in the tomahawk.jar. Since the sandbox is
> experimental it doesn't need its own release cycle. Also, stuff moves
> from sandbox to tomahawk so you will often update both anyways. The
> examples for tomahawk would be the current examples (minus sandbox).
> The sandbox examples would go under sandbox.
I think the experimental stuff should only released as a nighly build.
>
>
>
> Yes faster release cycles would be good. I suppose MyFaces commons
> will be released everytime *either* the core or tomahawk stuff is
> released. There are bound to be minor changes either time. That
> still saves us the trouble of branching, testing and merging the core
> stuff.
>
and tobago is released :-)
> We had talked about a core project a while ago - but as an
> svn:external. I like this better. You are correct that branching and
> tagging will be much easier.
>
>
:-)
>
> I had thought about this. Is there a way to tell Maven "Use my local
> repository if it is newer then the maven repository?" Things could
> get kind of confusing if you are using your latest commons code in the
> IDE but Maven is using the last official release ..
Yes, of cause.
I will describe a possible release cycle of myfaces-commons, first.
Current development version 1.1.4-SNAPSHOT
Ready for a release create a branch 1.1.4 (maven-release-plugin)
and then change the version in trunk to 1.1.5-SNAPSHOT.
On the branch you can apply last patches and finally perform a release.
If you have made changes in tomahawk that depends on
myfaces-commons-1.1.5-SNAPSHOT you must change the dependency in the
tomahawk pom. If you have made local changes in commons for tomahawk,
you only must install a new myfaces-commons-1.1.5-SNAPSHOT in your local
repository with mvn install(and change the dependeny to 1.1.5-SNAPSHOT).
After you are finished you have to commit your changes in common and
tomahawk.
A continuum server updates automatically the myfaces snapshot repository.
If an other developer perform an update of tomahawk, the next call of
mvn fetch the new snapshot of commons into his local repository from the
myfaces snapshot repository.
TODO setup continuum
TODO define the snapshot repository
>
> Sean
>
Regards
Bernd
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Mike Kienenberger <mk...@gmail.com>.
+1 for Sean's proposal..
On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
> I'll attempt the reorg tomorrow if I don't hear any objections.
> Please try to get your comments in by then since its simpler to do
> email iterations vs. svn iterations I'll make a copy of everything in
> the legacy folder and we can always go back or further refine.
>
> Lets try to get the svn shuffle over with ASAP so we can get back to
> the nightly builds and another release.
>
> Sean
>
> On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
> > On 1/5/06, Bernd Bohmann <be...@atanion.com> wrote:
> > > Here is a more detail description of my thoughts
> > >
> > > If myfaces is a project without separate release cycle, a possible svn
> > > structure:
> > >
> > > myfaces/trunk/api
> > > myfaces/trunk/impl
> > > myfaces/trunk/commons
> > > myfaces/trunk/tomahawk
> > > myfaces/trunk/sandbox
> > > myfaces/trunk/examples or the examples belongs to the subprojects
> > > myfaces/trunk/assembly or build-tool(s) with checkstyle configuration,
> > > assembly maven plugin...
> > >
> > > I like the parent refs in the pom.xml. I don't like the svn externals
> > > they are painful for branching and taging.
> >
> > Can you give me the arguments for parent refs? I still haven't heard
> > a good reason. I'm not against the idea, I just don't know what they
> > give you (other then a common version.) I think we can all agree that
> > the externals are suboptimal. The question is what to do about it.
> >
> > > If myfaces has separate release cycles, a possible structure would be:
> > >
> > > myfaces/core/trunk/api
> > > myfaces/core/trunk/impl
> > > myfaces/core/trunk/example
> > > myfaces/core/trunk/assembly
> > >
> > > myfaces/commons/trunk
> > >
> > > myfaces/tomahawk/trunk
> > > myfaces/tomahawk/trunk/example
> > > myfaces/tomahawk/trunk/assembly
> > >
> > >
> > > myfaces/sandbox/trunk
> > > myfaces/sandbox/trunk/example
> > > myfaces/sandbox/trunk/assembly
> > >
> > > maybe a
> > >
> > > myfaces/common-examples/trunk
> > >
> > > and
> > >
> > > myfaces/[build|build-tool(s)]/trunk for checkstyle pmd maven-plugins
> >
> > A good start. Here is a revised proposal based on Bernd's original one
> >
> > core
> > ====
> > myfaces/core/trunk/api
> > myfaces/core/trunk/impl
> > myfaces/core/trunk/assembly
> >
> > commons
> > =======
> > myfaces/commons/trunk
> >
> > tomahawk
> > =======
> >
> > myfaces/tomahawk/trunk
> > myfaces/tomahawk/trunk/example
> > myfaces/tomahawk/trunk/assembly
> > myfaces/sandbox/trunk
> > myfaces/sandbox/trunk/example
> > myfaces/sandbox/trunk/assembly
> >
> > maven-tools
> > =========
> >
> > custom maven plugins, etc.
> >
> > NOTES:
> >
> > I took out the examples from core. The examples are 99% tomahawk
> > related (other then the blank example which shows basic setup.) I
> > think its easier to just leave examples out of core instead of having
> > two copies, separate examples or svn externals.
> >
> > I merged sandbox and tomahawk together. A while back we decided to
> > put the sandbox stuff in the tomahawk.jar. Since the sandbox is
> > experimental it doesn't need its own release cycle. Also, stuff moves
> > from sandbox to tomahawk so you will often update both anyways. The
> > examples for tomahawk would be the current examples (minus sandbox).
> > The sandbox examples would go under sandbox.
> >
> > > With the second option I expect faster release cycles. This would be
> > > nice for a faster tobago and adf integration.
> >
> > Yes faster release cycles would be good. I suppose MyFaces commons
> > will be released everytime *either* the core or tomahawk stuff is
> > released. There are bound to be minor changes either time. That
> > still saves us the trouble of branching, testing and merging the core
> > stuff.
> >
> > We had talked about a core project a while ago - but as an
> > svn:external. I like this better. You are correct that branching and
> > tagging will be much easier.
> >
> > > Which a snapshot repository or a mavenized released version on a maven
> > > repository, it should not be a problem to checkout tomahawk only and
> > > compile it (indepent of the first option or the second option).
> >
> > I had thought about this. Is there a way to tell Maven "Use my local
> > repository if it is newer then the maven repository?" Things could
> > get kind of confusing if you are using your latest commons code in the
> > IDE but Maven is using the last official release ...
> >
> > > Best Regards
> > >
> > > Bernd
> >
> > Sean
> >
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
I'll attempt the reorg tomorrow if I don't hear any objections.
Please try to get your comments in by then since its simpler to do
email iterations vs. svn iterations I'll make a copy of everything in
the legacy folder and we can always go back or further refine.
Lets try to get the svn shuffle over with ASAP so we can get back to
the nightly builds and another release.
Sean
On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
> On 1/5/06, Bernd Bohmann <be...@atanion.com> wrote:
> > Here is a more detail description of my thoughts
> >
> > If myfaces is a project without separate release cycle, a possible svn
> > structure:
> >
> > myfaces/trunk/api
> > myfaces/trunk/impl
> > myfaces/trunk/commons
> > myfaces/trunk/tomahawk
> > myfaces/trunk/sandbox
> > myfaces/trunk/examples or the examples belongs to the subprojects
> > myfaces/trunk/assembly or build-tool(s) with checkstyle configuration,
> > assembly maven plugin...
> >
> > I like the parent refs in the pom.xml. I don't like the svn externals
> > they are painful for branching and taging.
>
> Can you give me the arguments for parent refs? I still haven't heard
> a good reason. I'm not against the idea, I just don't know what they
> give you (other then a common version.) I think we can all agree that
> the externals are suboptimal. The question is what to do about it.
>
> > If myfaces has separate release cycles, a possible structure would be:
> >
> > myfaces/core/trunk/api
> > myfaces/core/trunk/impl
> > myfaces/core/trunk/example
> > myfaces/core/trunk/assembly
> >
> > myfaces/commons/trunk
> >
> > myfaces/tomahawk/trunk
> > myfaces/tomahawk/trunk/example
> > myfaces/tomahawk/trunk/assembly
> >
> >
> > myfaces/sandbox/trunk
> > myfaces/sandbox/trunk/example
> > myfaces/sandbox/trunk/assembly
> >
> > maybe a
> >
> > myfaces/common-examples/trunk
> >
> > and
> >
> > myfaces/[build|build-tool(s)]/trunk for checkstyle pmd maven-plugins
>
> A good start. Here is a revised proposal based on Bernd's original one
>
> core
> ====
> myfaces/core/trunk/api
> myfaces/core/trunk/impl
> myfaces/core/trunk/assembly
>
> commons
> =======
> myfaces/commons/trunk
>
> tomahawk
> =======
>
> myfaces/tomahawk/trunk
> myfaces/tomahawk/trunk/example
> myfaces/tomahawk/trunk/assembly
> myfaces/sandbox/trunk
> myfaces/sandbox/trunk/example
> myfaces/sandbox/trunk/assembly
>
> maven-tools
> =========
>
> custom maven plugins, etc.
>
> NOTES:
>
> I took out the examples from core. The examples are 99% tomahawk
> related (other then the blank example which shows basic setup.) I
> think its easier to just leave examples out of core instead of having
> two copies, separate examples or svn externals.
>
> I merged sandbox and tomahawk together. A while back we decided to
> put the sandbox stuff in the tomahawk.jar. Since the sandbox is
> experimental it doesn't need its own release cycle. Also, stuff moves
> from sandbox to tomahawk so you will often update both anyways. The
> examples for tomahawk would be the current examples (minus sandbox).
> The sandbox examples would go under sandbox.
>
> > With the second option I expect faster release cycles. This would be
> > nice for a faster tobago and adf integration.
>
> Yes faster release cycles would be good. I suppose MyFaces commons
> will be released everytime *either* the core or tomahawk stuff is
> released. There are bound to be minor changes either time. That
> still saves us the trouble of branching, testing and merging the core
> stuff.
>
> We had talked about a core project a while ago - but as an
> svn:external. I like this better. You are correct that branching and
> tagging will be much easier.
>
> > Which a snapshot repository or a mavenized released version on a maven
> > repository, it should not be a problem to checkout tomahawk only and
> > compile it (indepent of the first option or the second option).
>
> I had thought about this. Is there a way to tell Maven "Use my local
> repository if it is newer then the maven repository?" Things could
> get kind of confusing if you are using your latest commons code in the
> IDE but Maven is using the last official release ...
>
> > Best Regards
> >
> > Bernd
>
> Sean
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
> For Struts I'm resisting putting *any* dependencies in the parent pom,
> even if it means repeating a couple of them (servlet-api and junit).
> In practice, the transitive dependency mechanism will work better than
> inheritance for making sure each module has the dependencies it needs
> to compile.
I agree. Lets keep the dependencies out of the parent POM for the
reasons Wendy mentioned. IMO there's no need to keep them consistent
as Bill is suggesting. If tomahawk has a dependency on
commons-lang-1.2 and impl is dependent on commons-lang-1.1 that is
fine by me. In fact, its preferred. That way if I'm only using
MyFaces for the JSF implementation I can stick with v. 1.1 of the
commons-lang dependency that's already in my app server or whatever.
On the other hand. The list of commiters, the mailing list info, etc.
should be consistent and only defined in one place. A while back I
noticed the Struts site was not consistent with contributor lists and
I'm assuming it was due to not using this parent feature.
> Wendy
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Martin Marinschek <ma...@gmail.com>.
No prob!
regards,
Martin
On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> Martin,
>
> For now we are using tomahawk.jar and sandbox.jar. Just until we get
> maven up and running. Lets discuss this on a separate thread when we
> are done. (Bernd has a few good counter arguments as well.)
>
> Sean
>
> On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> > OK that is a good argument for it. I guess we can still rely on
> > "tomahawk" as the part that tells you its not just an implementation.
> >
> > Sean
> >
> > On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > Well, my reasoning for changing it was that the users would see - at
> > > one glance - which myfaces-libs they have in their lib-folders.
> > >
> > > Thing is also that if we go down the "myfaces"-road with sandbox, but
> > > not with tomahawk, there will be a discrepancy, right?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> > > > I kind of like it just as tomahawk.jar. Its easier to pronounce and
> > > > doesn't get confused with myfaces implementation. We don't want our
> > > > users to assume that they need the MyFaces implementation. That's my
> > > > reasoning for keeping it the way it is. I'm open to changing it if
> > > > the other commiters agree with you.
> > > >
> > > > Sean
> > > >
> > > > On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > > > @Sean, Bernd: sounds good. Let's go with that! My project setup in
> > > > > intellij is automatically generated anyways ;)
> > > > >
> > > > > One final comment: If it's not done already - let's also change the
> > > > > name for tomahawk to myfaces-tomahawk...
> > > > >
> > > > > all other modules have that prefix already in place.
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> > > > > >
> > > > > >
> > > > > > Sean Schofield schrieb:
> > > > > > > Quick question:
> > > > > > >
> > > > > > > Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> > > > > > > for the module to be called myfaces-api? I would prefer just api ...
> > > > > > >
> > > > > > It should be myfaces-api and myfaces-impl. Please look at the maven svn
> > > > > > structure.
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > http://www.irian.at
> > > > >
> > > > > Your JSF powerhouse -
> > > > > JSF Consulting, Development and
> > > > > Courses in English and German
> > > > >
> > > > > Professional Support for Apache MyFaces
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
Martin,
For now we are using tomahawk.jar and sandbox.jar. Just until we get
maven up and running. Lets discuss this on a separate thread when we
are done. (Bernd has a few good counter arguments as well.)
Sean
On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> OK that is a good argument for it. I guess we can still rely on
> "tomahawk" as the part that tells you its not just an implementation.
>
> Sean
>
> On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Well, my reasoning for changing it was that the users would see - at
> > one glance - which myfaces-libs they have in their lib-folders.
> >
> > Thing is also that if we go down the "myfaces"-road with sandbox, but
> > not with tomahawk, there will be a discrepancy, right?
> >
> > regards,
> >
> > Martin
> >
> > On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> > > I kind of like it just as tomahawk.jar. Its easier to pronounce and
> > > doesn't get confused with myfaces implementation. We don't want our
> > > users to assume that they need the MyFaces implementation. That's my
> > > reasoning for keeping it the way it is. I'm open to changing it if
> > > the other commiters agree with you.
> > >
> > > Sean
> > >
> > > On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > > @Sean, Bernd: sounds good. Let's go with that! My project setup in
> > > > intellij is automatically generated anyways ;)
> > > >
> > > > One final comment: If it's not done already - let's also change the
> > > > name for tomahawk to myfaces-tomahawk...
> > > >
> > > > all other modules have that prefix already in place.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> > > > >
> > > > >
> > > > > Sean Schofield schrieb:
> > > > > > Quick question:
> > > > > >
> > > > > > Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> > > > > > for the module to be called myfaces-api? I would prefer just api ...
> > > > > >
> > > > > It should be myfaces-api and myfaces-impl. Please look at the maven svn
> > > > > structure.
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> Quick question:
>
> Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> for the module to be called myfaces-api? I would prefer just api ...
The <module> needs to match the directory name, but the <artifactId>
can be something different.
/struts/current/action/pom.xml has:
<artifactId>struts-action</artifactId>
--
Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> Bernd,
>
> It seems like Wendy says we can call the directory/module api and the
> artifact myfaces-api. What is wrong with that? That is better IMO.
The <module> is file-system path based, so with
<module>../whatever</module> there must really be a parallel
"whatever" directory.
But <artifactId> doesn't necessarily have to match the directory name.
This probably deviates from Maven's Official Rules though. :)
You're already (or were) doing something similar with the examples--
the directory name is "blank" but the <artifactId> is
myfaces-example-blank.
--
Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
The practice is one artifact per module and the module/directory has the
same name.
My experience was continuum has a problem with multimodule project if
module name and artifact name are different. Maybe a bug maybe solved
but maven follows the same scheme.
tobago and adf follows the same scheme :-)
Sean Schofield schrieb:
> Bernd,
>
> It seems like Wendy says we can call the directory/module api and the
> artifact myfaces-api. What is wrong with that? That is better IMO.
>
> Sean
>
> On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
>
>>
>>Sean Schofield schrieb:
>>
>>>Quick question:
>>>
>>>Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
>>>for the module to be called myfaces-api? I would prefer just api ...
>>>
>>
>>It should be myfaces-api and myfaces-impl. Please look at the maven svn
>>structure.
>>
>
>
--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
Bernd,
It seems like Wendy says we can call the directory/module api and the
artifact myfaces-api. What is wrong with that? That is better IMO.
Sean
On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
>
>
> Sean Schofield schrieb:
> > Quick question:
> >
> > Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> > for the module to be called myfaces-api? I would prefer just api ...
> >
> It should be myfaces-api and myfaces-impl. Please look at the maven svn
> structure.
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
OK that is a good argument for it. I guess we can still rely on
"tomahawk" as the part that tells you its not just an implementation.
Sean
On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> Well, my reasoning for changing it was that the users would see - at
> one glance - which myfaces-libs they have in their lib-folders.
>
> Thing is also that if we go down the "myfaces"-road with sandbox, but
> not with tomahawk, there will be a discrepancy, right?
>
> regards,
>
> Martin
>
> On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> > I kind of like it just as tomahawk.jar. Its easier to pronounce and
> > doesn't get confused with myfaces implementation. We don't want our
> > users to assume that they need the MyFaces implementation. That's my
> > reasoning for keeping it the way it is. I'm open to changing it if
> > the other commiters agree with you.
> >
> > Sean
> >
> > On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > @Sean, Bernd: sounds good. Let's go with that! My project setup in
> > > intellij is automatically generated anyways ;)
> > >
> > > One final comment: If it's not done already - let's also change the
> > > name for tomahawk to myfaces-tomahawk...
> > >
> > > all other modules have that prefix already in place.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> > > >
> > > >
> > > > Sean Schofield schrieb:
> > > > > Quick question:
> > > > >
> > > > > Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> > > > > for the module to be called myfaces-api? I would prefer just api ...
> > > > >
> > > > It should be myfaces-api and myfaces-impl. Please look at the maven svn
> > > > structure.
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Martin Marinschek <ma...@gmail.com>.
Well, my reasoning for changing it was that the users would see - at
one glance - which myfaces-libs they have in their lib-folders.
Thing is also that if we go down the "myfaces"-road with sandbox, but
not with tomahawk, there will be a discrepancy, right?
regards,
Martin
On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> I kind of like it just as tomahawk.jar. Its easier to pronounce and
> doesn't get confused with myfaces implementation. We don't want our
> users to assume that they need the MyFaces implementation. That's my
> reasoning for keeping it the way it is. I'm open to changing it if
> the other commiters agree with you.
>
> Sean
>
> On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> > @Sean, Bernd: sounds good. Let's go with that! My project setup in
> > intellij is automatically generated anyways ;)
> >
> > One final comment: If it's not done already - let's also change the
> > name for tomahawk to myfaces-tomahawk...
> >
> > all other modules have that prefix already in place.
> >
> > regards,
> >
> > Martin
> >
> > On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> > >
> > >
> > > Sean Schofield schrieb:
> > > > Quick question:
> > > >
> > > > Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> > > > for the module to be called myfaces-api? I would prefer just api ...
> > > >
> > > It should be myfaces-api and myfaces-impl. Please look at the maven svn
> > > structure.
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
I kind of like it just as tomahawk.jar. Its easier to pronounce and
doesn't get confused with myfaces implementation. We don't want our
users to assume that they need the MyFaces implementation. That's my
reasoning for keeping it the way it is. I'm open to changing it if
the other commiters agree with you.
Sean
On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> @Sean, Bernd: sounds good. Let's go with that! My project setup in
> intellij is automatically generated anyways ;)
>
> One final comment: If it's not done already - let's also change the
> name for tomahawk to myfaces-tomahawk...
>
> all other modules have that prefix already in place.
>
> regards,
>
> Martin
>
> On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> >
> >
> > Sean Schofield schrieb:
> > > Quick question:
> > >
> > > Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> > > for the module to be called myfaces-api? I would prefer just api ...
> > >
> > It should be myfaces-api and myfaces-impl. Please look at the maven svn
> > structure.
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
Can both of you add your TODO's to the wiki[1]? Just put your todos
at the top (move the svn reorg stuff down the list since its already
done.)
@Bernd,Wendy,Martin, Simon: Can you send me your ICQ or AIM accounts
(if you have them) offline? I'd like to be able to chat while I'm
reorging so we can test together (if you have time.)
Sean
[1] http://wiki.apache.org/myfaces/Maven2_Migration
On 1/7/06, Wendy Smoak <ws...@gmail.com> wrote:
> Another TODO: along with your first release into the
> 'org.apache.myfaces' group, there's a bunch of work to be done to
> "relocate" all of the existing artifacts in the repository.
>
> Without this, Maven won't know that myfaces:myfaces-impl:jar:1.1.1 and
> org.apache.myfaces:myfaces-impl:jar:1.1.2 are different versions of
> the same artifact.
>
> Briefly...
> svn co svn://svn.codehaus.org/maven/scm/repository/myfaces
> ... add <relocation> tags, create a patch, and open a JIRA ticket in MEV.
>
> See: http://maven.apache.org/guides/mini/guide-maven-evangelism.html
> http://maven.apache.org/maven-model/maven.html#class_relocation
>
> --
> Wendy
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Wendy Smoak <ws...@gmail.com>.
Another TODO: along with your first release into the
'org.apache.myfaces' group, there's a bunch of work to be done to
"relocate" all of the existing artifacts in the repository.
Without this, Maven won't know that myfaces:myfaces-impl:jar:1.1.1 and
org.apache.myfaces:myfaces-impl:jar:1.1.2 are different versions of
the same artifact.
Briefly...
svn co svn://svn.codehaus.org/maven/scm/repository/myfaces
... add <relocation> tags, create a patch, and open a JIRA ticket in MEV.
See: http://maven.apache.org/guides/mini/guide-maven-evangelism.html
http://maven.apache.org/maven-model/maven.html#class_relocation
--
Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Martin Marinschek <ma...@gmail.com>.
@Sean, Bernd: sounds good. Let's go with that! My project setup in
intellij is automatically generated anyways ;)
One final comment: If it's not done already - let's also change the
name for tomahawk to myfaces-tomahawk...
all other modules have that prefix already in place.
regards,
Martin
On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
>
>
> Sean Schofield schrieb:
> > Quick question:
> >
> > Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> > for the module to be called myfaces-api? I would prefer just api ...
> >
> It should be myfaces-api and myfaces-impl. Please look at the maven svn
> structure.
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
Sean Schofield schrieb:
> Quick question:
>
> Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
> for the module to be called myfaces-api? I would prefer just api ...
>
It should be myfaces-api and myfaces-impl. Please look at the maven svn
structure.
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
Quick question:
Do we have to name it: myfaces/core/trunk/myfaces-api/pom.xml in order
for the module to be called myfaces-api? I would prefer just api ...
Sean
On 1/7/06, Sean Schofield <se...@gmail.com> wrote:
> Well the zone is setup. I am checking with the PMC about getting you
> an account. Do you know how to setup continuum? (I do not.) Bill
> Dudney is also interested in continuum.
>
> I'm going to start the move now. Can you help me fix the POM's when
> I'm done? Lets get the install working again for the revised
> structure. Then we can get the assemble stuff together and I will
> write the chron scripts.
>
> Sean
>
> On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> >
> > Sean Schofield schrieb:
> > > Well there is a top level "core" directory now and api and impl are
> > > inside of that (so they can share a pom.) Also sandbox is inside of
> > > tomahawk. And examples have moved to be under tomahawk and sandbox.
> > >
> > > Those are the main changes. Basically you may have to adjust your IDE
> > > project file slightly to point to the new locations of things. It
> > > shouldn't be a big deal though and it will make for a *nice* mavenized
> > > release process. I think you will be very happy with the results.
> > >
> > > @Bernd: We have our zone setup. I will
> >
> > Hello Sean,
> >
> > how we can solve the TODOs?
> >
> > Bernd
> >
> >
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
Well the zone is setup. I am checking with the PMC about getting you
an account. Do you know how to setup continuum? (I do not.) Bill
Dudney is also interested in continuum.
I'm going to start the move now. Can you help me fix the POM's when
I'm done? Lets get the install working again for the revised
structure. Then we can get the assemble stuff together and I will
write the chron scripts.
Sean
On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
>
> Sean Schofield schrieb:
> > Well there is a top level "core" directory now and api and impl are
> > inside of that (so they can share a pom.) Also sandbox is inside of
> > tomahawk. And examples have moved to be under tomahawk and sandbox.
> >
> > Those are the main changes. Basically you may have to adjust your IDE
> > project file slightly to point to the new locations of things. It
> > shouldn't be a big deal though and it will make for a *nice* mavenized
> > release process. I think you will be very happy with the results.
> >
> > @Bernd: We have our zone setup. I will
>
> Hello Sean,
>
> how we can solve the TODOs?
>
> Bernd
>
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
Sean Schofield schrieb:
> Well there is a top level "core" directory now and api and impl are
> inside of that (so they can share a pom.) Also sandbox is inside of
> tomahawk. And examples have moved to be under tomahawk and sandbox.
>
> Those are the main changes. Basically you may have to adjust your IDE
> project file slightly to point to the new locations of things. It
> shouldn't be a big deal though and it will make for a *nice* mavenized
> release process. I think you will be very happy with the results.
>
> @Bernd: We have our zone setup. I will
Hello Sean,
how we can solve the TODOs?
Bernd
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
Well there is a top level "core" directory now and api and impl are
inside of that (so they can share a pom.) Also sandbox is inside of
tomahawk. And examples have moved to be under tomahawk and sandbox.
Those are the main changes. Basically you may have to adjust your IDE
project file slightly to point to the new locations of things. It
shouldn't be a big deal though and it will make for a *nice* mavenized
release process. I think you will be very happy with the results.
@Bernd: We have our zone setup. I will
On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> Ok, sorry.
>
> ;)
>
> I do like the structure now. I am all for a structure which is easiest
> in development and deployment, and by getting rid of the externals,
> deployment has become much easier, and I have liked the first maven
> structure for development already.
>
> I suppose there won't be any changes from this first structure with
> respect to development, right?
>
> regards,
>
> Martin
>
> On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> > Hello Martin,
> >
> > the resource issue is not a real problem, can solved later.
> > Please look at the latest Revised Reorg Proposal from Sean and me.
> >
> > Can you comment the proposed structure?
> >
> > Regards
> >
> > Bernd
> >
> > Martin Marinschek schrieb:
> > > @Sean,
> > >
> > > today, I'll try to spare an hour to think about that resources issue
> > > again. I still hope to find a solution ;)
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> > >
> > >>Yes, but until then, the clear winner is what makes it easiest to the
> > >>user, and that's Bernd's suggestion, right?
> > >>
> > >>the thing ought to work out of the box.
> > >>
> > >>regards,
> > >>
> > >>Martin
> > >>
> > >>On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> > >>
> > >>>And, once we get to JSF 1.2, "provided" is a clear
> > >>>winner because web containers will need to provide a JSF
> > >>>implementation.
> > >>>
> > >>>-- Adam
> > >>>
> > >>>
> > >>>On 1/6/06, Wendy Smoak <ws...@gmail.com> wrote:
> > >>>
> > >>>>On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> > >>>>
> > >>>>
> > >>>>>Anything that's a compile time dependency of library Foo
> > >>>>>where a user of Foo is responsible for supplying that dependency
> > >>>>>should be declared "provided".
> > >>>>
> > >>>>The Maven team usually puts it as "... can reasonably be expected to
> > >>>>be provided at runtime." But Maven 2.0 doesn't have anything in place
> > >>>>to deal with the "choice of implementations" situation, and so
> > >>>>'provided' is probably the best bet.
> > >>>>
> > >>>>This will put the responsibility of choosing an implementation on the
> > >>>>user-- either by declaring a dependency or installing it in the
> > >>>>container. (Or, I suppose, by using a container that already provides
> > >>>>it.) I think that's reasonable.
> > >>>>
> > >>>>--
> > >>>>Wendy
> > >>>>
> > >>>
> > >>
> > >>--
> > >>
> > >>http://www.irian.at
> > >>
> > >>Your JSF powerhouse -
> > >>JSF Consulting, Development and
> > >>Courses in English and German
> > >>
> > >>Professional Support for Apache MyFaces
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> > --
> > Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
> > Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
> > phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
Martin Marinschek schrieb:
> I suppose there won't be any changes from this first structure with
> respect to development, right?
Yes, I think only one change for the development.
mvn install
doesn't build all artifacts. But if the snapshot repository is up and
running you don't need to build all artifacts.
I have changed the proposal after your comment :-)
Regards
Bernd
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Martin Marinschek <ma...@gmail.com>.
Ok, sorry.
;)
I do like the structure now. I am all for a structure which is easiest
in development and deployment, and by getting rid of the externals,
deployment has become much easier, and I have liked the first maven
structure for development already.
I suppose there won't be any changes from this first structure with
respect to development, right?
regards,
Martin
On 1/7/06, Bernd Bohmann <be...@atanion.com> wrote:
> Hello Martin,
>
> the resource issue is not a real problem, can solved later.
> Please look at the latest Revised Reorg Proposal from Sean and me.
>
> Can you comment the proposed structure?
>
> Regards
>
> Bernd
>
> Martin Marinschek schrieb:
> > @Sean,
> >
> > today, I'll try to spare an hour to think about that resources issue
> > again. I still hope to find a solution ;)
> >
> > regards,
> >
> > Martin
> >
> > On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> >
> >>Yes, but until then, the clear winner is what makes it easiest to the
> >>user, and that's Bernd's suggestion, right?
> >>
> >>the thing ought to work out of the box.
> >>
> >>regards,
> >>
> >>Martin
> >>
> >>On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> >>
> >>>And, once we get to JSF 1.2, "provided" is a clear
> >>>winner because web containers will need to provide a JSF
> >>>implementation.
> >>>
> >>>-- Adam
> >>>
> >>>
> >>>On 1/6/06, Wendy Smoak <ws...@gmail.com> wrote:
> >>>
> >>>>On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>>Anything that's a compile time dependency of library Foo
> >>>>>where a user of Foo is responsible for supplying that dependency
> >>>>>should be declared "provided".
> >>>>
> >>>>The Maven team usually puts it as "... can reasonably be expected to
> >>>>be provided at runtime." But Maven 2.0 doesn't have anything in place
> >>>>to deal with the "choice of implementations" situation, and so
> >>>>'provided' is probably the best bet.
> >>>>
> >>>>This will put the responsibility of choosing an implementation on the
> >>>>user-- either by declaring a dependency or installing it in the
> >>>>container. (Or, I suppose, by using a container that already provides
> >>>>it.) I think that's reasonable.
> >>>>
> >>>>--
> >>>>Wendy
> >>>>
> >>>
> >>
> >>--
> >>
> >>http://www.irian.at
> >>
> >>Your JSF powerhouse -
> >>JSF Consulting, Development and
> >>Courses in English and German
> >>
> >>Professional Support for Apache MyFaces
> >>
> >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
> --
> Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
> Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
> phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
Hello Martin,
the resource issue is not a real problem, can solved later.
Please look at the latest Revised Reorg Proposal from Sean and me.
Can you comment the proposed structure?
Regards
Bernd
Martin Marinschek schrieb:
> @Sean,
>
> today, I'll try to spare an hour to think about that resources issue
> again. I still hope to find a solution ;)
>
> regards,
>
> Martin
>
> On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
>
>>Yes, but until then, the clear winner is what makes it easiest to the
>>user, and that's Bernd's suggestion, right?
>>
>>the thing ought to work out of the box.
>>
>>regards,
>>
>>Martin
>>
>>On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
>>
>>>And, once we get to JSF 1.2, "provided" is a clear
>>>winner because web containers will need to provide a JSF
>>>implementation.
>>>
>>>-- Adam
>>>
>>>
>>>On 1/6/06, Wendy Smoak <ws...@gmail.com> wrote:
>>>
>>>>On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
>>>>
>>>>
>>>>>Anything that's a compile time dependency of library Foo
>>>>>where a user of Foo is responsible for supplying that dependency
>>>>>should be declared "provided".
>>>>
>>>>The Maven team usually puts it as "... can reasonably be expected to
>>>>be provided at runtime." But Maven 2.0 doesn't have anything in place
>>>>to deal with the "choice of implementations" situation, and so
>>>>'provided' is probably the best bet.
>>>>
>>>>This will put the responsibility of choosing an implementation on the
>>>>user-- either by declaring a dependency or installing it in the
>>>>container. (Or, I suppose, by using a container that already provides
>>>>it.) I think that's reasonable.
>>>>
>>>>--
>>>>Wendy
>>>>
>>>
>>
>>--
>>
>>http://www.irian.at
>>
>>Your JSF powerhouse -
>>JSF Consulting, Development and
>>Courses in English and German
>>
>>Professional Support for Apache MyFaces
>>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Martin Marinschek <ma...@gmail.com>.
@Sean,
today, I'll try to spare an hour to think about that resources issue
again. I still hope to find a solution ;)
regards,
Martin
On 1/7/06, Martin Marinschek <ma...@gmail.com> wrote:
> Yes, but until then, the clear winner is what makes it easiest to the
> user, and that's Bernd's suggestion, right?
>
> the thing ought to work out of the box.
>
> regards,
>
> Martin
>
> On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> > And, once we get to JSF 1.2, "provided" is a clear
> > winner because web containers will need to provide a JSF
> > implementation.
> >
> > -- Adam
> >
> >
> > On 1/6/06, Wendy Smoak <ws...@gmail.com> wrote:
> > > On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > > Anything that's a compile time dependency of library Foo
> > > > where a user of Foo is responsible for supplying that dependency
> > > > should be declared "provided".
> > >
> > > The Maven team usually puts it as "... can reasonably be expected to
> > > be provided at runtime." But Maven 2.0 doesn't have anything in place
> > > to deal with the "choice of implementations" situation, and so
> > > 'provided' is probably the best bet.
> > >
> > > This will put the responsibility of choosing an implementation on the
> > > user-- either by declaring a dependency or installing it in the
> > > container. (Or, I suppose, by using a container that already provides
> > > it.) I think that's reasonable.
> > >
> > > --
> > > Wendy
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Martin Marinschek <ma...@gmail.com>.
Yes, but until then, the clear winner is what makes it easiest to the
user, and that's Bernd's suggestion, right?
the thing ought to work out of the box.
regards,
Martin
On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> And, once we get to JSF 1.2, "provided" is a clear
> winner because web containers will need to provide a JSF
> implementation.
>
> -- Adam
>
>
> On 1/6/06, Wendy Smoak <ws...@gmail.com> wrote:
> > On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > > Anything that's a compile time dependency of library Foo
> > > where a user of Foo is responsible for supplying that dependency
> > > should be declared "provided".
> >
> > The Maven team usually puts it as "... can reasonably be expected to
> > be provided at runtime." But Maven 2.0 doesn't have anything in place
> > to deal with the "choice of implementations" situation, and so
> > 'provided' is probably the best bet.
> >
> > This will put the responsibility of choosing an implementation on the
> > user-- either by declaring a dependency or installing it in the
> > container. (Or, I suppose, by using a container that already provides
> > it.) I think that's reasonable.
> >
> > --
> > Wendy
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Adam Winer <aw...@gmail.com>.
And, once we get to JSF 1.2, "provided" is a clear
winner because web containers will need to provide a JSF
implementation.
-- Adam
On 1/6/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
>
> > Anything that's a compile time dependency of library Foo
> > where a user of Foo is responsible for supplying that dependency
> > should be declared "provided".
>
> The Maven team usually puts it as "... can reasonably be expected to
> be provided at runtime." But Maven 2.0 doesn't have anything in place
> to deal with the "choice of implementations" situation, and so
> 'provided' is probably the best bet.
>
> This will put the responsibility of choosing an implementation on the
> user-- either by declaring a dependency or installing it in the
> container. (Or, I suppose, by using a container that already provides
> it.) I think that's reasonable.
>
> --
> Wendy
>
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Bernd Bohmann <be...@atanion.com>.
I don't think provided would be a good idea.
If someone don't use tomahawk with myfaces-api and myfaces-impl.
It would be easier to exclude myfaces-api and myfaces-impl and add a
dependency to the RI. On the other side it would be painful for the
normal user, the normal user would expect a compile dependency to
myfaces-imp and myfaces-api.
Adam Winer schrieb:
> On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
>
>
>>>There are transitive dependencies between commons and impl, or commons
>>>and tomahawk.
>>
>>Tomahawk actually has a dependency on api (a compile time one.) If
>>you were to build tomahawk using maven you would need it. If you were
>>to use tomahawk with your own project you would not need it. I'm
>>thinking the "provided" scope would help us here?
>
>
> Yep, "provided" would be a good fit here.
>
> Anything that's a compile time dependency of library Foo
> where a user of Foo is responsible for supplying that dependency
> should be declared "provided".
>
> -- Adam
>
--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/6/06, Adam Winer <aw...@gmail.com> wrote:
> Anything that's a compile time dependency of library Foo
> where a user of Foo is responsible for supplying that dependency
> should be declared "provided".
The Maven team usually puts it as "... can reasonably be expected to
be provided at runtime." But Maven 2.0 doesn't have anything in place
to deal with the "choice of implementations" situation, and so
'provided' is probably the best bet.
This will put the responsibility of choosing an implementation on the
user-- either by declaring a dependency or installing it in the
container. (Or, I suppose, by using a container that already provides
it.) I think that's reasonable.
--
Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Adam Winer <aw...@gmail.com>.
On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
> > There are transitive dependencies between commons and impl, or commons
> > and tomahawk.
>
> Tomahawk actually has a dependency on api (a compile time one.) If
> you were to build tomahawk using maven you would need it. If you were
> to use tomahawk with your own project you would not need it. I'm
> thinking the "provided" scope would help us here?
Yep, "provided" would be a good fit here.
Anything that's a compile time dependency of library Foo
where a user of Foo is responsible for supplying that dependency
should be declared "provided".
-- Adam
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
> > Won't this be the case either way. The dependencies for tomahawk are
> > the dependencies for tomahawk. It doesn't matter if Maven learns this
> > exclusively from the tomahawk.pom or from a combination of myfaces.pom
> > (parent) and tomahawk.pom. Is this reasoning correct?
>
> I don't believe so. Myfaces-impl can be used without tomahawk. Tomahawk
> can be used without Myfaces-impl. So neither has "transitive
> dependencies" on the other project.
That wasn't my assertion. My assertion was that if you have a
dependency for tomahawk (lets say commons-digester as a random
example) it doesn't matter whether you have the depedency in the top
level myfaces/pom.xml or tomahawk/pom.xml. Bill said that if it was
in myfaces/pom.xml you would automatically get the digester dependency
when you ran maven on the tomahawk project. I agreee with him but my
counter assertion was you would also get it if the same dependency was
in tomahawk/pom.xml. In otherwords, listing shared dependencies in
myfaces/pom.xml gives you very little (and in fact may result in other
problems that Wendy and I pointed out.)
I've heard the case for why you would define certain plugins in the
master pom but I haven't heard the case for dependencies yet.
Particularly when I don't think there is a single one that would apply
to all modules.
> And as an earlier post pointed out, myfaces-impl may depend on
> commons-lang 1.1 while tomahawk may depend on commons-lang 1.2. In this
> case, people only wanting to use the core myfaces (not tomahawk) should
> be able to use just commons-lang 1.1. Only if they add tomahawk do they
> need to upgrade the commons-lang library.
Right. So this is the argument for keeping the dependencies in their own POMs.
> There are transitive dependencies between commons and impl, or commons
> and tomahawk.
Tomahawk actually has a dependency on api (a compile time one.) If
you were to build tomahawk using maven you would need it. If you were
to use tomahawk with your own project you would not need it. I'm
thinking the "provided" scope would help us here?
> Regards,
>
> Simon
>
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven
changes
Posted by Simon Kitching <sk...@obsidium.com>.
Sean Schofield wrote:
>> Do we really end up with everything from the top level in the lib
>> dir? What I'm thinking is something like this being in a 'user' project.
>>
>> <dependency>
>> <groupid>org.apache.myfaces</groupId>
>> <artifactId>tomahawk</artifactId>
>> </depdency>
>>
>> This will cause the transitive dependency thing to pull in everything
>> that tomahawk depends on but won't touch the top level pom as I
>> understand it anyway. Am I wrong about this?
>
> Won't this be the case either way. The dependencies for tomahawk are
> the dependencies for tomahawk. It doesn't matter if Maven learns this
> exclusively from the tomahawk.pom or from a combination of myfaces.pom
> (parent) and tomahawk.pom. Is this reasoning correct?
I don't believe so. Myfaces-impl can be used without tomahawk. Tomahawk
can be used without Myfaces-impl. So neither has "transitive
dependencies" on the other project.
And as an earlier post pointed out, myfaces-impl may depend on
commons-lang 1.1 while tomahawk may depend on commons-lang 1.2. In this
case, people only wanting to use the core myfaces (not tomahawk) should
be able to use just commons-lang 1.1. Only if they add tomahawk do they
need to upgrade the commons-lang library.
There are transitive dependencies between commons and impl, or commons
and tomahawk.
Regards,
Simon
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
> Do we really end up with everything from the top level in the lib
> dir? What I'm thinking is something like this being in a 'user' project.
>
> <dependency>
> <groupid>org.apache.myfaces</groupId>
> <artifactId>tomahawk</artifactId>
> </depdency>
>
> This will cause the transitive dependency thing to pull in everything
> that tomahawk depends on but won't touch the top level pom as I
> understand it anyway. Am I wrong about this?
Won't this be the case either way. The dependencies for tomahawk are
the dependencies for tomahawk. It doesn't matter if Maven learns this
exclusively from the tomahawk.pom or from a combination of myfaces.pom
(parent) and tomahawk.pom. Is this reasoning correct?
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by John Fallows <jo...@gmail.com>.
On 1/9/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 1/9/06, Sean Schofield <se...@gmail.com> wrote:
>
> > How would it distinguish
> > what was an actual dependency vs. what dependency was used in 4 out of
> > 6 subprojects?
>
> Assuming you're talking about <dependencyManagement>, things in that
> section don't have any effect until they are declared in
> <dependencies> by a module. At that point, you can take advantage of
> the inheritance and leave out the version number and (I think) scope.
>
That's right. So it would be safe to put things like Servlet API, JUnit (or
anything else that didn't get picked up automatically as a transitive
dependency) into the parent POM's <dependencyManagement> section. The child
projects would then reference these dependencyManagement entries by groupId
and artifactId, omitting the version for sure, and also scope, although
inheriting the scope seemed broken in the lead-up to Maven 2.0 final but I
think it's fixed now. :-)
Kind Regards,
John Fallows.
--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/9/06, Sean Schofield <se...@gmail.com> wrote:
> How would it distinguish
> what was an actual dependency vs. what dependency was used in 4 out of
> 6 subprojects?
Assuming you're talking about <dependencyManagement>, things in that
section don't have any effect until they are declared in
<dependencies> by a module. At that point, you can take advantage of
the inheritance and leave out the version number and (I think) scope.
--
Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
John,
That maven quote you provided doesn't really contradict what Wendy is
saying. I read that same statement and it seems ambiguous to me. Are
you arguing for doing this in MyFaces? Its hard to imagine the
dependency reports coming out right (ie. not including the parent
depedencies that really weren't needed.) How would it distinguish
what was an actual dependency vs. what dependency was used in 4 out of
6 subprojects?
Sean
On 1/9/06, John Fallows <jo...@gmail.com> wrote:
> On 1/5/06, Wendy Smoak <ws...@gmail.com> wrote:
> > On 1/5/06, Bill Dudney <bd...@mac.com> wrote:
> >
> > > Do we really end up with everything from the top level in the lib
> > > dir? What I'm thinking is something like this being in a 'user' project.
> > >
> > > <dependency>
> > > <groupid>org.apache.myfaces</groupId>
> > > <artifactId>tomahawk</artifactId>
> > > </depdency>
> > >
> > > This will cause the transitive dependency thing to pull in everything
> > > that tomahawk depends on but won't touch the top level pom as I
> > > understand it anyway. Am I wrong about this?
> >
> > I don't know for sure, I'd have to experiment with it. I think that
> > if Tomahawk inherits dependencies, then they "belong" to Tomahawk no
> > matter where they originally came from. If your webapp depends on
> > Tomahawk, you're going to get all of them.
> >
> > > I hate to repeat the info though...
> >
> > Lesser of two evils? :) My first experiences with m2 were fending off
> > unwanted transitive dependencies and submitting patches for poms in
> > the repository so my own webapps would contain the right things.
> >
> > I'd rather do the work up front, and make sure that the users get
> > clean poms that express exactly the right dependencies for each
> > module. And so far the only duplication I'm seeing is from the
> > dependencies that are not transitive (the ones with test or provided
> > scope.)
> >
>
> There is a significant difference in behavior between making everything a
> dependency of the parent pom, versus pre-defining each dependency in the
> <dependencyManagement> section of the parent pom, and then referencing each
> relevant entry as a dependency (by groupId + artifactId) in the child pom.
>
> Here's the quote from the Maven Dependency Mechanism documentation.
>
> "The dependency management section is a mechanism for centralizing
> dependency information. When you have a set of projects that inherits a
> common parent it's possible to put all information about the dependency in
> the common POM and have simpler references to the artifacts in the child
> POMs."
>
> --
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>
> @Wendy: Were you seeing problems when defining your common dependencies in
> the parent pom in the <dependencies> section, or in the
> <dependencyManagement> section?
>
> Kind Regards,
> John Fallows.
> --
> Author Pro JSF and Ajax: Building Rich Internet Components
> http://www.apress.com/book/bookDisplay.html?bID=10044
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/9/06, John Fallows <jo...@gmail.com> wrote:
> @Wendy: Were you seeing problems when defining your common dependencies in
> the parent pom in the <dependencies> section, or in the
> <dependencyManagement> section?
The problem with the Maven 1 build for Struts is that there are things
in the "common" build file that are _not_ common to all of the
sub-projects. I don't want that to happen with the m2 build.
What I'm finding so far is that for Struts, the transitive dependency
mechanism is taking care of the things that would otherwise need to be
inherited. Struts Action has most of the dependencies, and the
half-dozen modules that depend on struts-action will transitively pick
up those dependencies.
The two dependencies that I've had to repeat are the Servlet API,
because it is marked 'provided' and so is not transitive, and JUnit,
which is usually in test scope. JUnit could probably go in the parent
pom without breaking anything... but I just *know* that as soon as I
put Servlet in the parent pom, we'll adopt some sub-project that
doesn't need it and I'll regret having done it.
--
Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by John Fallows <jo...@gmail.com>.
On 1/5/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 1/5/06, Bill Dudney <bd...@mac.com> wrote:
>
> > Do we really end up with everything from the top level in the lib
> > dir? What I'm thinking is something like this being in a 'user' project.
> >
> > <dependency>
> > <groupid>org.apache.myfaces</groupId>
> > <artifactId>tomahawk</artifactId>
> > </depdency>
> >
> > This will cause the transitive dependency thing to pull in everything
> > that tomahawk depends on but won't touch the top level pom as I
> > understand it anyway. Am I wrong about this?
>
> I don't know for sure, I'd have to experiment with it. I think that
> if Tomahawk inherits dependencies, then they "belong" to Tomahawk no
> matter where they originally came from. If your webapp depends on
> Tomahawk, you're going to get all of them.
>
> > I hate to repeat the info though...
>
> Lesser of two evils? :) My first experiences with m2 were fending off
> unwanted transitive dependencies and submitting patches for poms in
> the repository so my own webapps would contain the right things.
>
> I'd rather do the work up front, and make sure that the users get
> clean poms that express exactly the right dependencies for each
> module. And so far the only duplication I'm seeing is from the
> dependencies that are not transitive (the ones with test or provided
> scope.)
>
There is a significant difference in behavior between making everything a
dependency of the parent pom, versus pre-defining each dependency in the
<dependencyManagement> section of the parent pom, and then referencing each
relevant entry as a dependency (by groupId + artifactId) in the child pom.
Here's the quote from the Maven Dependency Mechanism documentation.
"The dependency management section is a mechanism for centralizing
dependency information. When you have a set of projects that inherits a
common parent it's possible to put all information about the dependency in
the common POM and have simpler references to the artifacts in the child
POMs."
--
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
@Wendy: Were you seeing problems when defining your common dependencies in
the parent pom in the <dependencies> section, or in the
<dependencyManagement> section?
Kind Regards,
John Fallows.
--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/5/06, Bill Dudney <bd...@mac.com> wrote:
> Do we really end up with everything from the top level in the lib
> dir? What I'm thinking is something like this being in a 'user' project.
>
> <dependency>
> <groupid>org.apache.myfaces</groupId>
> <artifactId>tomahawk</artifactId>
> </depdency>
>
> This will cause the transitive dependency thing to pull in everything
> that tomahawk depends on but won't touch the top level pom as I
> understand it anyway. Am I wrong about this?
I don't know for sure, I'd have to experiment with it. I think that
if Tomahawk inherits dependencies, then they "belong" to Tomahawk no
matter where they originally came from. If your webapp depends on
Tomahawk, you're going to get all of them.
> I hate to repeat the info though...
Lesser of two evils? :) My first experiences with m2 were fending off
unwanted transitive dependencies and submitting patches for poms in
the repository so my own webapps would contain the right things.
I'd rather do the work up front, and make sure that the users get
clean poms that express exactly the right dependencies for each
module. And so far the only duplication I'm seeing is from the
dependencies that are not transitive (the ones with test or provided
scope.)
--
Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Bill Dudney <bd...@mac.com>.
Hi Wendy,
On Jan 5, 2006, at 2:18 PM, Wendy Smoak wrote:
> On 1/5/06, Bill Dudney <bd...@mac.com> wrote:
>
>> Well if more than one of the modules depends on it (not all) then I'd
>> put it in the root. That way your are consistently specifying the
>> version you depend on. As far as the dependency report goes each
>> module will get a more specific one, the top level will define all
>> the dependences for everything. In some respects it could be
>> considered better to have the top level specify each and every
>> dependency even if its only used in one module.
>
> I don't agree with this at all. For one thing, any webapps you try to
> build will inherit all of the dependencies and they will all land in
> WEB-INF/lib. You'll then have a mess of exclusions trying to keep
> things out. And the list of dependencies will be useless to someone
> trying to figure out what any one module really depends upon. I
> haven't tried it, but I'm also concerned that the poms created during
> the release process will list too many dependencies.
>
Do we really end up with everything from the top level in the lib
dir? What I'm thinking is something like this being in a 'user' project.
<dependency>
<groupid>org.apache.myfaces</groupId>
<artifactId>tomahawk</artifactId>
</depdency>
This will cause the transitive dependency thing to pull in everything
that tomahawk depends on but won't touch the top level pom as I
understand it anyway. Am I wrong about this?
> For Struts I'm resisting putting *any* dependencies in the parent pom,
> even if it means repeating a couple of them (servlet-api and junit).
> In practice, the transitive dependency mechanism will work better than
> inheritance for making sure each module has the dependencies it needs
> to compile.
>
I hate to repeat the info though...
> --
> Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/5/06, Bill Dudney <bd...@mac.com> wrote:
> Well if more than one of the modules depends on it (not all) then I'd
> put it in the root. That way your are consistently specifying the
> version you depend on. As far as the dependency report goes each
> module will get a more specific one, the top level will define all
> the dependences for everything. In some respects it could be
> considered better to have the top level specify each and every
> dependency even if its only used in one module.
I don't agree with this at all. For one thing, any webapps you try to
build will inherit all of the dependencies and they will all land in
WEB-INF/lib. You'll then have a mess of exclusions trying to keep
things out. And the list of dependencies will be useless to someone
trying to figure out what any one module really depends upon. I
haven't tried it, but I'm also concerned that the poms created during
the release process will list too many dependencies.
For Struts I'm resisting putting *any* dependencies in the parent pom,
even if it means repeating a couple of them (servlet-api and junit).
In practice, the transitive dependency mechanism will work better than
inheritance for making sure each module has the dependencies it needs
to compile.
--
Wendy
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Bill Dudney <bd...@mac.com>.
On Jan 5, 2006, at 1:55 PM, Sean Schofield wrote:
>> The other cool thing with a 'parent pom' is that you'd only specify
>> the dependency version once in the top level pom so that we would not
>> have to change it over and over again in the subprojects/modules.
>
> I can't think of a single dependency that would apply to *all*
> projects. If it doesn't apply to all modules then you don't want it
> in the "root" POM do you? Otherwise it shows up in the dependency
> reports even though the dependency is not there ...
>
Well if more than one of the modules depends on it (not all) then I'd
put it in the root. That way your are consistently specifying the
version you depend on. As far as the dependency report goes each
module will get a more specific one, the top level will define all
the dependences for everything. In some respects it could be
considered better to have the top level specify each and every
dependency even if its only used in one module.
> We wouldn't put commons in the top level POM either would we? That
> isn't even created until later on down the line. Plus different
> modules would depend on different versions (since we are releasing
> independently now ..)
>
Well I'd set the dependency during the development cycle to be
consistent. Then at release time for a module you could fix it to the
version you are about to release, publish the module then fix it back
to the snapshot version.
I'm not sure the process is fully baked in my mind though. I'll have
to put another thread out for discussion on that.
-bd-
>> -bd-
>
> Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Sean Schofield <se...@gmail.com>.
> The other cool thing with a 'parent pom' is that you'd only specify
> the dependency version once in the top level pom so that we would not
> have to change it over and over again in the subprojects/modules.
I can't think of a single dependency that would apply to *all*
projects. If it doesn't apply to all modules then you don't want it
in the "root" POM do you? Otherwise it shows up in the dependency
reports even though the dependency is not there ...
We wouldn't put commons in the top level POM either would we? That
isn't even created until later on down the line. Plus different
modules would depend on different versions (since we are releasing
independently now ..)
> -bd-
Sean
Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes
Posted by Bill Dudney <bd...@mac.com>.
>
>> Which a snapshot repository or a mavenized released version on a
>> maven
>> repository, it should not be a problem to checkout tomahawk only and
>> compile it (indepent of the first option or the second option).
>
> I had thought about this. Is there a way to tell Maven "Use my local
> repository if it is newer then the maven repository?" Things could
> get kind of confusing if you are using your latest commons code in the
> IDE but Maven is using the last official release ...
I need to respond to the other stuff too but this I've beaten my head
against my monitor on far to much :-)
So that others don't have to I'll respond now...
When you do a 'mvn install' the product (typically the jar file
produced by the build) is installed in the local repository (~/.m2/
repository), and maven won't download it unless the pom explicitly
depends on a different version.
So for example
myfaces/commons/pom.xml->version = 1.1.2-SNAPSHOT
myfaces/impl/pom.xml -> dependency/groupId=org.apache.myfaces
artifactId=myfaces-commons version=1.1.2-SNAPSHOT
when in myfaces/commons if you do a 'mvn install' then 1.1.2-SNAPSHOT
will be installed locally, when you do the same from myfaces/impl you
would pick up the jar just installed instead of downloading anything.
The other cool thing with a 'parent pom' is that you'd only specify
the dependency version once in the top level pom so that we would not
have to change it over and over again in the subprojects/modules.
Also you would be able to do an 'mvn install' from the top level and
maven will take care of building everything in order for you and get
it all into your local repo (~/.m2/repository).
TTFN,
-bd-