[maven] Latest maven changes

[Sean Schofield <se...@gmail.com>]

I added a 'publish' project which has a POM that deals exclusively
with the assembly stuff.  Eventually it will also publish the nightly
builds to the website and publish the website as well.

I added javadoc for all subprojects (its in the top level POM.)  We
want it for every subproject except the examples.  Is there a way to
exclude this for just examples?  Also, if we remove the parent
reference in a project like tomahawk, can we still inherit from the
parent when the tomahawk POM is called from the parent POM?

Proposal: We eliminate the refs to the parent POM.  I don't see a
reason to have them really.  I think users should be able to build
each of the subprojects independently.  Maybe we could also get rid of
the reports from each individual project POM since site generation is
only really necessary for the entire project.

What do you think?

Sean

Re: [maven] Latest maven changes

[Bill Dudney <bd...@mac.com>]

On Jan 5, 2006, at 3:48 AM, Simon Kitching wrote:

> Hi,
>
> Sooner or later, the MyFaces core will stabilise while tomahawk  
> charges
> ahead. So at *some* time the release cycles will have to separate. I
> think it's beneficial to split them sooner rather than later, so I'd
> like to see a structure set up now that makes that easier.
>

Agreed, with maven as I understand it we can easily have separate  
releases for the modules.

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

Dependencies can be spelled out in the various module poms and each  
one can have its own version etc.

So from impl we could do a release of the impl (presumably less often  
than tomahawk) and from the top level we could build everything with  
the same command (mvn install).

This possibly belongs in the other thread about our svn reorg. I'm  
totally behind getting rid of externals.

TTFN,

-bd-

Re: [maven] Latest maven changes

[Bernd Bohmann <be...@atanion.com>]

Simon Kitching schrieb:
> Hi,
> 
> Sooner or later, the MyFaces core will stabilise while tomahawk charges
> ahead. So at *some* time the release cycles will have to separate. I
> think it's beneficial to split them sooner rather than later, so I'd
> like to see a structure set up now that makes that easier.
>
Yes

> Sooner or later, real "bugfix" releases should also be supported;
> MyFaces has just ignored that issue so far. Again, this is much easier
> to do when the libraries have separate release cycles; I'd hate to see a
> new myfaces-impl.jar release just because a nasty bug was found in
> t:dataTable...
> 
Yes :-)
> On the subject of externals, I dislike them a lot. Sometimes they are
> necessary, but I'd prefer to see them kept to a minimum.
> 
Yes
> Note that it's perfectly possible in SVN to copy several dirs into a
> tags dir, eg
>     svn cp myfaces/trunk/commons tags/spec/x.y.z/commons
>     svn cp myfaces/trunk/api     tags/spec/x.y.z/api
> to make a tag dir containing the two parts of MyFaces required to
> implement the specification (commons and core). In other words, how the
> subprojects are grouped for releases doesn't have to mirror their
> repository layout.
Yes, this is possible.
But the current stucture is:

myfaces/commons/trunk
myfaces/api/trunk

Do you mean:

svn cp myfaces/commons/trunk tags/spec/x.y.z/commons
svn cp myfaces/api/trunk     tags/spec/x.y.z/api

Why do you want to change the layout in a branch or tag only?

You only need some svn moves and some changes in the poms. Every user 
can see the current state of the structure and what he can expect in the 
next release cycle.

And I don't think this works with the release-plugin from maven.
Maven provides some little help for performing a release.
If we decide to use maven we should go the maven way.

See:

http://maven.apache.org/guides/mini/guide-releasing.html

But I never try it.

It makes creating a tag fractionally more complicated
> (it *is* nicer just to be able to copy some common root dir) but I would
> still prefer this over externals.

This would be correct. if svn doesn't support move.
And if externals are a common use case, why I never see it?


> 
> Regards,
> 
> Simon


Regards

Bernd

Re: [maven] Latest maven changes

[Sean Schofield <se...@gmail.com>]

Never mind.  I saw your +1 on the other thread.

On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
> Definitely.  We basically decided that a long time ago.  We just
> haven't done a release like this yet (but that will change.)
>
> So do you like the revised proposal (as far as layout goes?)
>
> Sean
>
> On 1/5/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
> > > True.  The one issue to be aware of is when commons changes.  If
> > > containers ship with an older version of MyFaces (including the
> > > commons jar) there could be conflicts.  No big deal though.  We just
> > > make sure to remind people to upgrade commons if they are downloading
> > > the "tomahawk only" release.  (We should probably include the
> > > commons.jar in the tomahawk release as well.)
> >
> > Another "sooner rather than later" task we should complete is to make
> > the build process package commons separately for impl and for
> > tomahawk.    Then we don't have to worry about conflicts.
> >
> > We don't want to force a new release of impl just because we've added
> > extra functionality to commons.
> >
>

Re: [maven] Latest maven changes

[Sean Schofield <se...@gmail.com>]

Definitely.  We basically decided that a long time ago.  We just
haven't done a release like this yet (but that will change.)

So do you like the revised proposal (as far as layout goes?)

Sean

On 1/5/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
> > True.  The one issue to be aware of is when commons changes.  If
> > containers ship with an older version of MyFaces (including the
> > commons jar) there could be conflicts.  No big deal though.  We just
> > make sure to remind people to upgrade commons if they are downloading
> > the "tomahawk only" release.  (We should probably include the
> > commons.jar in the tomahawk release as well.)
>
> Another "sooner rather than later" task we should complete is to make
> the build process package commons separately for impl and for
> tomahawk.    Then we don't have to worry about conflicts.
>
> We don't want to force a new release of impl just because we've added
> extra functionality to commons.
>

Re: [maven] Latest maven changes

[Mike Kienenberger <mk...@gmail.com>]

On 1/5/06, Sean Schofield <se...@gmail.com> wrote:
> True.  The one issue to be aware of is when commons changes.  If
> containers ship with an older version of MyFaces (including the
> commons jar) there could be conflicts.  No big deal though.  We just
> make sure to remind people to upgrade commons if they are downloading
> the "tomahawk only" release.  (We should probably include the
> commons.jar in the tomahawk release as well.)

Another "sooner rather than later" task we should complete is to make
the build process package commons separately for impl and for
tomahawk.    Then we don't have to worry about conflicts.

We don't want to force a new release of impl just because we've added
extra functionality to commons.

Re: [maven] Latest maven changes

[Sean Schofield <se...@gmail.com>]

> Hi,
>
> Sooner or later, the MyFaces core will stabilise while tomahawk charges
> ahead. So at *some* time the release cycles will have to separate. I
> think it's beneficial to split them sooner rather than later, so I'd
> like to see a structure set up now that makes that easier.

I think you are correct on this Simon.  While we have everyone focused
on Maven we might figure out a solution to this.

> Sooner or later, real "bugfix" releases should also be supported;
> MyFaces has just ignored that issue so far. Again, this is much easier
> to do when the libraries have separate release cycles; I'd hate to see a
> new myfaces-impl.jar release just because a nasty bug was found in
> t:dataTable...

True.  The one issue to be aware of is when commons changes.  If
containers ship with an older version of MyFaces (including the
commons jar) there could be conflicts.  No big deal though.  We just
make sure to remind people to upgrade commons if they are downloading
the "tomahawk only" release.  (We should probably include the
commons.jar in the tomahawk release as well.)

> On the subject of externals, I dislike them a lot. Sometimes they are
> necessary, but I'd prefer to see them kept to a minimum.

+1 for minimizing externals.  As we see from the poor user trying to
access 1.1.1 source code, the externals can really make a mess of
things.

There are 2 easy steps we can take to reduce usage of externals.

1.) Get rid of the shared build directory.  (Already done - maven
makes it easier to do recursive builds so we don't need the "one file
to build them all" ant script.)

2.) Use svn copy for the "release" directory (instead of using externals.)

> Note that it's perfectly possible in SVN to copy several dirs into a
> tags dir, eg
>     svn cp myfaces/trunk/commons tags/spec/x.y.z/commons
>     svn cp myfaces/trunk/api     tags/spec/x.y.z/api
> to make a tag dir containing the two parts of MyFaces required to
> implement the specification (commons and core). In other words, how the
> subprojects are grouped for releases doesn't have to mirror their
> repository layout. It makes creating a tag fractionally more complicated
> (it *is* nicer just to be able to copy some common root dir) but I would
> still prefer this over externals.

The tags are the only place where I believe externals make sense at
all (and that's all we would use them for now that we have maven.)  I
guess you are suggesting we make a tags module and use the "assembly"
step to pull things together?  That might work.  I'm not sure how the
XSLT step would go though ...

> Regards,
>
> Simon

Sean

Re: [maven] Latest maven changes

[Simon Kitching <sk...@apache.org>]

Hi,

Sooner or later, the MyFaces core will stabilise while tomahawk charges
ahead. So at *some* time the release cycles will have to separate. I
think it's beneficial to split them sooner rather than later, so I'd
like to see a structure set up now that makes that easier.

Sooner or later, real "bugfix" releases should also be supported;
MyFaces has just ignored that issue so far. Again, this is much easier
to do when the libraries have separate release cycles; I'd hate to see a
new myfaces-impl.jar release just because a nasty bug was found in
t:dataTable...

On the subject of externals, I dislike them a lot. Sometimes they are
necessary, but I'd prefer to see them kept to a minimum.

Note that it's perfectly possible in SVN to copy several dirs into a
tags dir, eg
    svn cp myfaces/trunk/commons tags/spec/x.y.z/commons
    svn cp myfaces/trunk/api     tags/spec/x.y.z/api
to make a tag dir containing the two parts of MyFaces required to
implement the specification (commons and core). In other words, how the
subprojects are grouped for releases doesn't have to mirror their
repository layout. It makes creating a tag fractionally more complicated
(it *is* nicer just to be able to copy some common root dir) but I would
still prefer this over externals.

Regards,

Simon

On Thu, 2006-01-05 at 09:53 +0100, Bernd Bohmann wrote:
> Here is a more detail description of my thoughts
> 
> If myfaces is a project without separate release cycle, a possible svn 
> structure:

[snip]

> With the second option I expect faster release cycles. This would be 
> nice for a faster tobago and adf integration.
> 
> 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).

[snip]

> 
> Best Regards
> 
> Bernd
> 
> 
> Martin Marinschek schrieb:
> > I'll put in my 2cents.
> > 
> > Let's see if we can get the machine to work with those ;)
> > 
> > currently, we treat myfaces as a project with an integrated
> > release-cycle. We don't release things separately here so far.
> > 
> > (except tobago).
> > 
> > So I'd say we should go with this for now - I'd say that the
> > Maven-POMs are easily enough changed. I really like how they decreased
> > the ant-clutter.
> > 
> > regards,
> > 
> > Martin
> > 
> 

Re: [maven] Latest maven changes

[Bernd Bohmann <be...@atanion.com>]

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.

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

With the second option I expect faster release cycles. This would be 
nice for a faster tobago and adf integration.

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).

Best Regards

Bernd


Martin Marinschek schrieb:
> I'll put in my 2cents.
> 
> Let's see if we can get the machine to work with those ;)
> 
> currently, we treat myfaces as a project with an integrated
> release-cycle. We don't release things separately here so far.
> 
> (except tobago).
> 
> So I'd say we should go with this for now - I'd say that the
> Maven-POMs are easily enough changed. I really like how they decreased
> the ant-clutter.
> 
> regards,
> 
> Martin
> 

Re: [maven] Latest maven changes

[Martin Marinschek <ma...@gmail.com>]

I'll put in my 2cents.

Let's see if we can get the machine to work with those ;)

currently, we treat myfaces as a project with an integrated
release-cycle. We don't release things separately here so far.

(except tobago).

So I'd say we should go with this for now - I'd say that the
Maven-POMs are easily enough changed. I really like how they decreased
the ant-clutter.

regards,

Martin

On 1/5/06, Bernd Bohmann <be...@atanion.com> wrote:
> Hello Sean,
>
> I think we should talk about the release cycle of each artifact, first.
> If artifacts have the same release cycle and version, the artifact
> should belongs to the same svn module. And should organised as
> multimodule build with parent-child poms, of cause. The assembly
> descriptor should be a part of this svn module. Because we should be
> able to reproduce a version from svn. (and creating a branch whould be
> easy, too) (look at the thread 'problem getting 1.1.1 from svn')
>
> The examples for tomahawk, sandbox.. should be a part of the projects
> and not independ. (The same reason as assembly)
>
> > I added a 'publish' project which has a POM that deals exclusively
> > with the assembly stuff.  Eventually it will also publish the nightly
> > builds to the website and publish the website as well.
> >
>
> Who invokes the nightly build?
>
> > I added javadoc for all subprojects (its in the top level POM.)  We
> > want it for every subproject except the examples.  Is there a way to
> > exclude this for just examples?
>
>
>   Also, if we remove the parent
> > reference in a project like tomahawk, can we still inherit from the
> > parent when the tomahawk POM is called from the parent POM?
>
> I think this is not possible, the opposite yes.
>
> > Proposal: We eliminate the refs to the parent POM.  I don't see a
> > reason to have them really.
>
> Why you don't like it? (after 4 days)
>
> I think users should be able to build
> > each of the subprojects independently.
>
> If we have a SNAPSHOT repository this should not be a problem.
>
>   Maybe we could also get rid of
> > the reports from each individual project POM since site generation is
> > only really necessary for the entire project.
>
> Maybe some reports are useful.
>
> >
> > What do you think?
> >
> > Sean
> >
>
> Maybe the site should be a own module and of cause with a parent ref.
>
> 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
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [maven] Latest maven changes

[Bernd Bohmann <be...@atanion.com>]

Hello Sean,

I think we should talk about the release cycle of each artifact, first.
If artifacts have the same release cycle and version, the artifact 
should belongs to the same svn module. And should organised as 
multimodule build with parent-child poms, of cause. The assembly 
descriptor should be a part of this svn module. Because we should be 
able to reproduce a version from svn. (and creating a branch whould be 
easy, too) (look at the thread 'problem getting 1.1.1 from svn')

The examples for tomahawk, sandbox.. should be a part of the projects 
and not independ. (The same reason as assembly)

> I added a 'publish' project which has a POM that deals exclusively
> with the assembly stuff.  Eventually it will also publish the nightly
> builds to the website and publish the website as well.
>

Who invokes the nightly build?

> I added javadoc for all subprojects (its in the top level POM.)  We
> want it for every subproject except the examples.  Is there a way to
> exclude this for just examples? 


  Also, if we remove the parent
> reference in a project like tomahawk, can we still inherit from the
> parent when the tomahawk POM is called from the parent POM?

I think this is not possible, the opposite yes.

> Proposal: We eliminate the refs to the parent POM.  I don't see a
> reason to have them really.  

Why you don't like it? (after 4 days)

I think users should be able to build
> each of the subprojects independently. 

If we have a SNAPSHOT repository this should not be a problem.

  Maybe we could also get rid of
> the reports from each individual project POM since site generation is
> only really necessary for the entire project.

Maybe some reports are useful.

> 
> What do you think?
> 
> Sean
> 

Maybe the site should be a own module and of cause with a parent ref.

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