[maven] We need to make a decision

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

OK,

We have been discussing a few important maven-related decisions these
past few days.  Its time to make a decision and move on.  Here is my
proposal.  I'd like to see a couple of +1's and then we can get back
to business.  Everything is held up by this matter so lets bring it to
a close.

1.) Make the master pom an official artifact of myfaces.  Its a little
weird to have a POM only artifact in the public maven repository but
who cares?  Its not a big deal. Everything is downloaded
automatically.  This seems to make more sense then hiding it in
api/pom.xml (where it is now.)  The master pom is needed my all
modules therefore its a dependency.  It could sit in myfaces/pom.xml
except each of the modules is releasable on its own schedule so IMO
there is no other logical alternative.

2.) Directory names vs. artifiact names.  Bernd has suggested a
preference for the two matching but this is definitely not a
requirement for maven.  I propose core/trunk/api instead of
core/trunk/myfaces-api.  There is no *technical* reason for doing this
*either way.*  My personal preference is to keep the directory names
as short as possible.  The final product will be call myfaces-api.jar
either way.

3.) Establish a core module.  So we have myfaces/core/trunk/api and
myfaces/core/trunk/impl.  Bernd and I had started down this road and
stopped at his request.  I think the issues that concerned us then can
be addressed now.  So can we agree to do this?

Keep in mind nothing is final.  We can always revisit the decision if
we found we made a mistake.  But it will be easier to make the right
decision the first time around.

Sean

Re: [maven] We need to make a decision

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

> > I agree.  Ted Husted and I made this point several times on the PMC
> > mailing list during the early days of the discussion.  Oracle wanted
> > to keep things confidential until they had internal approval.  I was
> > against any serious discussion that did not take place in public.
>
> Ok, we will wait.

No you misunderstood me.  That was a long time ago.  Everything about
ADF should now be discussed in public.  So you don't have to wait
(just use another thread.)

> Bernd

Sean

Re: [maven] We need to make a decision

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

You can call it what ever, I expect we removed it later :-)

Bernd

Sean Schofield schrieb:
> Bernd,
> 
> I'm ok to compromise and call the poms "project."  So
> tomahawk-project, sandbox-project, etc.
> 
> What about the master pom?  Do you prefer a separate myfaces-project
> just for the pom?  Or do we keep it myfaces-master?  We need to decide
> quickly because I want to get the nightly builds started.
> 
> Sean
> 
> On 1/16/06, Bernd Bohmann <be...@atanion.com> wrote:
> 
>>
>>Sean Schofield schrieb:
>>
>>
>>
>>>We're talking about the result (longer directory names) which I think
>>>everyone can have an opinion on regardless of their Maven knowledge.
>>>So far nobody has presented a maven *requirement* that we use longer
>>>names.  Wendy has pointed out several times now about how the artifact
>>>names and directories do not have to match.
>>>
>>
>>Your only question was do you prefer a short name. If you ask me I would
>>agree. But this is not the core question but some of the consequences.
>>
>>
>>
>>>Since maven doesn't require it, I prefer to keep the names the way
>>>they were before we went down the maven road.  We made other changes
>>>to our svn to accomodate maven b/c they were not as disagreeable and
>>>because using the maven directory layout makes the pom's much cleaner.
>>>
>>>
>>>
>>>>For me it is the best outcome.
>>>
>>>
>>>Ok.
>>>
>>>
>>>
>>>>But I hope you get some more maven background now and you change your mind.
>>>>And please look at the structure of the maven project, maybe you
>>>>understand me then.
>>>
>>>
>>>I've looked at the maven project.  I find it confusing.  Here's what I
>>>would expect to see:
>>>
>>>maven
>>>maven/core
>>>maven/continuum
>>>maven/plugins
>>>maven/plugins/foo
>>>maven/plugins/bar
>>>... etc.
>>>
>>
>> From my experience the struture of maven make sense
>>
>>
>>>Something like that.  But that's not how they chose to organize it.
>>>Its their project so they can organize it how they want.
>>>
>>>
>>>
>>>>All of adf would be tomahawk? I don't expect it. Some of the parts can
>>>>be merge with tomahawk. I think this must be technical decision and not
>>>>only discuss internal in the PMC.
>>>
>>>
>>>I agree.  Ted Husted and I made this point several times on the PMC
>>>mailing list during the early days of the discussion.  Oracle wanted
>>>to keep things confidential until they had internal approval.  I was
>>>against any serious discussion that did not take place in public.
>>
>>Ok, we will wait.
>>
>>>
>>>
>>>
>>>For the record, very little was decided and very little was discussed
>>>on the PMC list.  Pretty much everything was deferred until Oracle
>>>decided to make the source publicly available.
>>>
>>>One issue that I raised was that the ADF stuff should make as much use
>>>of myfaces-commons as possible (including moving tomahawk and the impl
>>>to the ADF way when it made sense.)  A bunch of PMC members said "Yes.
>>> I agree" to that sentiment.  The other issue that I raised was that
>>>we should try to consolidate the number of components when there was
>>>overlap and that the components should all live in tomahawk.  Again, I
>>>received a lot of +1's for that statement.
>>
>>This is the renderkit part of adf. But what about the other stuff?
>>
>>>So even though nothing has been decided I have a pretty good idea of
>>>how myself and other PMC members will vote when it comes down to it.
>>>
>>>As for the private PMC discussions, I agree with you.  This should
>>>have been 100% on the dev list but since not everyone wanted to do
>>>this, I deferred to the others.
>>>
>>>
>>>
>>>>Do you expect a 1.2 api from myfaces?
>>>
>>>
>>>You mean a jsf 1.2 implementation?  Yes.  Will it be its own
>>>subproject?  No.  That's my personal opinion based on what I know now.
>>> The api is already pretty stable now.  So we would probably create a
>>>branch for the 1.1 implementation once we started work on 1.2.
>>>
>>>
>>>
>>>>Is was only an example.
>>>>What is your problem with tobago-core?
>>>
>>>
>>>What is your problem with tobago/core?  We seem to be going in circles here ...
>>>
>>
>>Yes :-)
>>
>>>>Sorry, I'm talking about their source repository. They don't have a
>>>>different way they implements the maven way.
>>>
>>>
>>>I looked at it.  I prefer the shorter names.  Again, there is only so
>>>many ways to say the same thing.
>>>
>>>
>>>
>>>>>Why not a different group id for all of the subprojects?
>>>>>
>>>>>org.apache.myfaces.core
>>>>>org.apache.myfaces.commons
>>>>>org.apache.myfaces.tomahawk
>>>>>org.apache.myfaces.sandbox
>>>>>
>>>>
>>>>Why not, but I would prefer org.apache.myfaces for core
>>>>If sandbox depends on tomahawk it should be org.apache.myfaces.tomahawk
>>>
>>>
>>>I'm not against org.apache.myfaces for core but it seems weird for
>>>org.apache.myfaces to apply to a subproject when the rest would have
>>>their own group ids.  What do you think?
>>>
>>
>>I think it is the root of myfaces.
>>
>>
>>>I think myfaces-maven makes perfect sense for things that are 100%
>>>maven related.  Master poms, plugins and archtypes are all
>>>maven-related.  So I think myfaces-maven is more
>>>appropriate/descriptive then myfaces-project.
>>>
>>
>>
>>>>>>myfaces-tomahawk
>>>>>>tomahawk
>>>>>
>>>>>
>>>>>+1 tomahawk
>>>>>
>>>>
>>>>ok, but which name for the tomahawk master pom?
>>>
>>>
>>>I was wondering the same thing.
>>>
>>>tomahawk-pom?
>>
>>tomahawk-project you would prefer tomahawk-maven but i don't like it
>>
>>
>>>
>>>>>>myfaces-sandbox
>>>>>>tomahawk-sandbox
>>>>>
>>>>>sandbox
>>>>>
>>>>
>>>>the master pom of sandbox can't be sandbox because the sandbox src pom
>>>>has already this artifactId
>>>
>>>
>>>sandbox-pom for the parent pom.  It makes sense doesn't it? Nobody
>>>will see these poms anyways so I don't think the names are too
>>>important.  Whatever we call the jar (myfaces-sandbox, sandbox or
>>>tomahawk-sandbox) that artifact id has to be reserved for
>>>sandbox/sandbox.
>>
>>Ok, sandbox-project
>>
>>
>>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] We need to make a decision

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

Bernd,

I'm ok to compromise and call the poms "project."  So
tomahawk-project, sandbox-project, etc.

What about the master pom?  Do you prefer a separate myfaces-project
just for the pom?  Or do we keep it myfaces-master?  We need to decide
quickly because I want to get the nightly builds started.

Sean

On 1/16/06, Bernd Bohmann <be...@atanion.com> wrote:
>
>
> Sean Schofield schrieb:
>
>
> >
> > We're talking about the result (longer directory names) which I think
> > everyone can have an opinion on regardless of their Maven knowledge.
> > So far nobody has presented a maven *requirement* that we use longer
> > names.  Wendy has pointed out several times now about how the artifact
> > names and directories do not have to match.
> >
> Your only question was do you prefer a short name. If you ask me I would
> agree. But this is not the core question but some of the consequences.
>
>
> > Since maven doesn't require it, I prefer to keep the names the way
> > they were before we went down the maven road.  We made other changes
> > to our svn to accomodate maven b/c they were not as disagreeable and
> > because using the maven directory layout makes the pom's much cleaner.
> >
> >
> >>For me it is the best outcome.
> >
> >
> > Ok.
> >
> >
> >>But I hope you get some more maven background now and you change your mind.
> >>And please look at the structure of the maven project, maybe you
> >>understand me then.
> >
> >
> > I've looked at the maven project.  I find it confusing.  Here's what I
> > would expect to see:
> >
> > maven
> > maven/core
> > maven/continuum
> > maven/plugins
> > maven/plugins/foo
> > maven/plugins/bar
> > ... etc.
> >
>  From my experience the struture of maven make sense
>
> > Something like that.  But that's not how they chose to organize it.
> > Its their project so they can organize it how they want.
> >
> >
> >>All of adf would be tomahawk? I don't expect it. Some of the parts can
> >>be merge with tomahawk. I think this must be technical decision and not
> >>only discuss internal in the PMC.
> >
> >
> > I agree.  Ted Husted and I made this point several times on the PMC
> > mailing list during the early days of the discussion.  Oracle wanted
> > to keep things confidential until they had internal approval.  I was
> > against any serious discussion that did not take place in public.
>
> Ok, we will wait.
> >
> >
> >
> >
> > For the record, very little was decided and very little was discussed
> > on the PMC list.  Pretty much everything was deferred until Oracle
> > decided to make the source publicly available.
> >
> > One issue that I raised was that the ADF stuff should make as much use
> > of myfaces-commons as possible (including moving tomahawk and the impl
> > to the ADF way when it made sense.)  A bunch of PMC members said "Yes.
> >  I agree" to that sentiment.  The other issue that I raised was that
> > we should try to consolidate the number of components when there was
> > overlap and that the components should all live in tomahawk.  Again, I
> > received a lot of +1's for that statement.
>
> This is the renderkit part of adf. But what about the other stuff?
> >
> > So even though nothing has been decided I have a pretty good idea of
> > how myself and other PMC members will vote when it comes down to it.
> >
> > As for the private PMC discussions, I agree with you.  This should
> > have been 100% on the dev list but since not everyone wanted to do
> > this, I deferred to the others.
> >
> >
> >>Do you expect a 1.2 api from myfaces?
> >
> >
> > You mean a jsf 1.2 implementation?  Yes.  Will it be its own
> > subproject?  No.  That's my personal opinion based on what I know now.
> >  The api is already pretty stable now.  So we would probably create a
> > branch for the 1.1 implementation once we started work on 1.2.
> >
> >
> >>Is was only an example.
> >>What is your problem with tobago-core?
> >
> >
> > What is your problem with tobago/core?  We seem to be going in circles here ...
> >
> Yes :-)
> >
> >>Sorry, I'm talking about their source repository. They don't have a
> >>different way they implements the maven way.
> >
> >
> > I looked at it.  I prefer the shorter names.  Again, there is only so
> > many ways to say the same thing.
> >
> >
> >>>Why not a different group id for all of the subprojects?
> >>>
> >>>org.apache.myfaces.core
> >>>org.apache.myfaces.commons
> >>>org.apache.myfaces.tomahawk
> >>>org.apache.myfaces.sandbox
> >>>
> >>
> >>Why not, but I would prefer org.apache.myfaces for core
> >>If sandbox depends on tomahawk it should be org.apache.myfaces.tomahawk
> >
> >
> > I'm not against org.apache.myfaces for core but it seems weird for
> > org.apache.myfaces to apply to a subproject when the rest would have
> > their own group ids.  What do you think?
> >
> I think it is the root of myfaces.
>
> >
> > I think myfaces-maven makes perfect sense for things that are 100%
> > maven related.  Master poms, plugins and archtypes are all
> > maven-related.  So I think myfaces-maven is more
> > appropriate/descriptive then myfaces-project.
> >
>
>
> >
> >>>>myfaces-tomahawk
> >>>>tomahawk
> >>>
> >>>
> >>>+1 tomahawk
> >>>
> >>
> >>ok, but which name for the tomahawk master pom?
> >
> >
> > I was wondering the same thing.
> >
> > tomahawk-pom?
>
> tomahawk-project you would prefer tomahawk-maven but i don't like it
>
> >
> >
> >>>>myfaces-sandbox
> >>>>tomahawk-sandbox
> >>>
> >>>sandbox
> >>>
> >>
> >>the master pom of sandbox can't be sandbox because the sandbox src pom
> >>has already this artifactId
> >
> >
> > sandbox-pom for the parent pom.  It makes sense doesn't it? Nobody
> > will see these poms anyways so I don't think the names are too
> > important.  Whatever we call the jar (myfaces-sandbox, sandbox or
> > tomahawk-sandbox) that artifact id has to be reserved for
> > sandbox/sandbox.
>
> Ok, sandbox-project
>
>
> Bernd
>

Re: [maven] We need to make a decision

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

Sean Schofield schrieb:


> 
> We're talking about the result (longer directory names) which I think
> everyone can have an opinion on regardless of their Maven knowledge. 
> So far nobody has presented a maven *requirement* that we use longer
> names.  Wendy has pointed out several times now about how the artifact
> names and directories do not have to match.
> 
Your only question was do you prefer a short name. If you ask me I would 
agree. But this is not the core question but some of the consequences.


> Since maven doesn't require it, I prefer to keep the names the way
> they were before we went down the maven road.  We made other changes
> to our svn to accomodate maven b/c they were not as disagreeable and
> because using the maven directory layout makes the pom's much cleaner.
> 
> 
>>For me it is the best outcome.
> 
> 
> Ok.
> 
> 
>>But I hope you get some more maven background now and you change your mind.
>>And please look at the structure of the maven project, maybe you
>>understand me then.
> 
> 
> I've looked at the maven project.  I find it confusing.  Here's what I
> would expect to see:
> 
> maven
> maven/core
> maven/continuum
> maven/plugins
> maven/plugins/foo
> maven/plugins/bar
> ... etc.
> 
 From my experience the struture of maven make sense

> Something like that.  But that's not how they chose to organize it. 
> Its their project so they can organize it how they want.
> 
> 
>>All of adf would be tomahawk? I don't expect it. Some of the parts can
>>be merge with tomahawk. I think this must be technical decision and not
>>only discuss internal in the PMC.
> 
> 
> I agree.  Ted Husted and I made this point several times on the PMC
> mailing list during the early days of the discussion.  Oracle wanted
> to keep things confidential until they had internal approval.  I was
> against any serious discussion that did not take place in public.

Ok, we will wait.
> 
> 
> 
> 
> For the record, very little was decided and very little was discussed
> on the PMC list.  Pretty much everything was deferred until Oracle
> decided to make the source publicly available.
> 
> One issue that I raised was that the ADF stuff should make as much use
> of myfaces-commons as possible (including moving tomahawk and the impl
> to the ADF way when it made sense.)  A bunch of PMC members said "Yes.
>  I agree" to that sentiment.  The other issue that I raised was that
> we should try to consolidate the number of components when there was
> overlap and that the components should all live in tomahawk.  Again, I
> received a lot of +1's for that statement.

This is the renderkit part of adf. But what about the other stuff?
> 
> So even though nothing has been decided I have a pretty good idea of
> how myself and other PMC members will vote when it comes down to it.
> 
> As for the private PMC discussions, I agree with you.  This should
> have been 100% on the dev list but since not everyone wanted to do
> this, I deferred to the others.
> 
> 
>>Do you expect a 1.2 api from myfaces?
> 
> 
> You mean a jsf 1.2 implementation?  Yes.  Will it be its own
> subproject?  No.  That's my personal opinion based on what I know now.
>  The api is already pretty stable now.  So we would probably create a
> branch for the 1.1 implementation once we started work on 1.2.
> 
> 
>>Is was only an example.
>>What is your problem with tobago-core?
> 
> 
> What is your problem with tobago/core?  We seem to be going in circles here ...
> 
Yes :-)
> 
>>Sorry, I'm talking about their source repository. They don't have a
>>different way they implements the maven way.
> 
> 
> I looked at it.  I prefer the shorter names.  Again, there is only so
> many ways to say the same thing.
> 
> 
>>>Why not a different group id for all of the subprojects?
>>>
>>>org.apache.myfaces.core
>>>org.apache.myfaces.commons
>>>org.apache.myfaces.tomahawk
>>>org.apache.myfaces.sandbox
>>>
>>
>>Why not, but I would prefer org.apache.myfaces for core
>>If sandbox depends on tomahawk it should be org.apache.myfaces.tomahawk
> 
> 
> I'm not against org.apache.myfaces for core but it seems weird for
> org.apache.myfaces to apply to a subproject when the rest would have
> their own group ids.  What do you think?
>
I think it is the root of myfaces.

> 
> I think myfaces-maven makes perfect sense for things that are 100%
> maven related.  Master poms, plugins and archtypes are all
> maven-related.  So I think myfaces-maven is more
> appropriate/descriptive then myfaces-project.
> 


> 
>>>>myfaces-tomahawk
>>>>tomahawk
>>>
>>>
>>>+1 tomahawk
>>>
>>
>>ok, but which name for the tomahawk master pom?
> 
> 
> I was wondering the same thing.
> 
> tomahawk-pom?

tomahawk-project you would prefer tomahawk-maven but i don't like it

> 
> 
>>>>myfaces-sandbox
>>>>tomahawk-sandbox
>>>
>>>sandbox
>>>
>>
>>the master pom of sandbox can't be sandbox because the sandbox src pom
>>has already this artifactId
> 
> 
> sandbox-pom for the parent pom.  It makes sense doesn't it? Nobody
> will see these poms anyways so I don't think the names are too
> important.  Whatever we call the jar (myfaces-sandbox, sandbox or
> tomahawk-sandbox) that artifact id has to be reserved for
> sandbox/sandbox.

Ok, sandbox-project


Bernd

Re: [maven] We need to make a decision

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

> Struts is not a maven2 project. Please look at the maven project.
> I don't see the advantages of your direction

Its a maven1 project.  As I said, ultimately it doesn't matter too
much what the other projects are doing.  They are useful reference
points but we're free to do things our own way as long as we
understand the consequences.

> I don't favor the short name for IDE reasons. In a IDE I see the
> artifactId the long name.

When people were saying they preferred the short names, you asked if
any of us used an IDE.  I figured you were citing that as a reason. 
It also came up a few times during our ICQ discussion.

> One description was a technical one. If myfaces grows I expect more
> directories with the same name.

If that happens those similar directories will be underneath a top
level subproject.  So there should be no name clash.  My preference is
for shorter names with a tight hierarchy.

> You don't describe any pro and cons. Everybody without a maven
> background would agree you. But many people with a maven background
> would prefer the maven conventions. Your vote is not really fair.

We're talking about the result (longer directory names) which I think
everyone can have an opinion on regardless of their Maven knowledge. 
So far nobody has presented a maven *requirement* that we use longer
names.  Wendy has pointed out several times now about how the artifact
names and directories do not have to match.

Since maven doesn't require it, I prefer to keep the names the way
they were before we went down the maven road.  We made other changes
to our svn to accomodate maven b/c they were not as disagreeable and
because using the maven directory layout makes the pom's much cleaner.

> For me it is the best outcome.

Ok.

> But I hope you get some more maven background now and you change your mind.
> And please look at the structure of the maven project, maybe you
> understand me then.

I've looked at the maven project.  I find it confusing.  Here's what I
would expect to see:

maven
maven/core
maven/continuum
maven/plugins
maven/plugins/foo
maven/plugins/bar
... etc.

Something like that.  But that's not how they chose to organize it. 
Its their project so they can organize it how they want.

> All of adf would be tomahawk? I don't expect it. Some of the parts can
> be merge with tomahawk. I think this must be technical decision and not
> only discuss internal in the PMC.

I agree.  Ted Husted and I made this point several times on the PMC
mailing list during the early days of the discussion.  Oracle wanted
to keep things confidential until they had internal approval.  I was
against any serious discussion that did not take place in public.

> Why this discussion is not open? Why we can't participate? What PMC
> means Technical Management Committee. Then I should ask the PMC if I
> have a technical problems instead asking the community.

For the record, very little was decided and very little was discussed
on the PMC list.  Pretty much everything was deferred until Oracle
decided to make the source publicly available.

One issue that I raised was that the ADF stuff should make as much use
of myfaces-commons as possible (including moving tomahawk and the impl
to the ADF way when it made sense.)  A bunch of PMC members said "Yes.
 I agree" to that sentiment.  The other issue that I raised was that
we should try to consolidate the number of components when there was
overlap and that the components should all live in tomahawk.  Again, I
received a lot of +1's for that statement.

So even though nothing has been decided I have a pretty good idea of
how myself and other PMC members will vote when it comes down to it.

As for the private PMC discussions, I agree with you.  This should
have been 100% on the dev list but since not everyone wanted to do
this, I deferred to the others.

> Do you expect a 1.2 api from myfaces?

You mean a jsf 1.2 implementation?  Yes.  Will it be its own
subproject?  No.  That's my personal opinion based on what I know now.
 The api is already pretty stable now.  So we would probably create a
branch for the 1.1 implementation once we started work on 1.2.

> Is was only an example.
> What is your problem with tobago-core?

What is your problem with tobago/core?  We seem to be going in circles here ...

> Sorry, I'm talking about their source repository. They don't have a
> different way they implements the maven way.

I looked at it.  I prefer the shorter names.  Again, there is only so
many ways to say the same thing.

> > Why not a different group id for all of the subprojects?
> >
> > org.apache.myfaces.core
> > org.apache.myfaces.commons
> > org.apache.myfaces.tomahawk
> > org.apache.myfaces.sandbox
> >
> Why not, but I would prefer org.apache.myfaces for core
> If sandbox depends on tomahawk it should be org.apache.myfaces.tomahawk

I'm not against org.apache.myfaces for core but it seems weird for
org.apache.myfaces to apply to a subproject when the rest would have
their own group ids.  What do you think?

> I would prefer myfaces-parent
> This is not the myfaces-maven project
> I would expect it for the the maven plugins and tools in myfaces
> >
> >>myfaces-project
> >
> >
> > What's this?
>
> a different suggestion for myfaces-parent

I think myfaces-maven makes perfect sense for things that are 100%
maven related.  Master poms, plugins and archtypes are all
maven-related.  So I think myfaces-maven is more
appropriate/descriptive then myfaces-project.

> >
> >>myfaces-tomahawk
> >>tomahawk
> >
> >
> > +1 tomahawk
> >
> ok, but which name for the tomahawk master pom?

I was wondering the same thing.

tomahawk-pom?

> >>myfaces-sandbox
> >>tomahawk-sandbox
> >
>
> >
> > sandbox
> >
> the master pom of sandbox can't be sandbox because the sandbox src pom
> has already this artifactId

sandbox-pom for the parent pom.  It makes sense doesn't it? Nobody
will see these poms anyways so I don't think the names are too
important.  Whatever we call the jar (myfaces-sandbox, sandbox or
tomahawk-sandbox) that artifact id has to be reserved for
sandbox/sandbox.

> >>myfaces-example-simple
> >>tomahawk-example-simple?
> >
> >
> > not sure
> >
> I'm too
>
>
>
> Bernd

Sean

Re: [maven] We need to make a decision

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

Sean Schofield schrieb:

> 
> I'm not sure.  I don't know much about their project.  Ultimately we
> have to decide what's best for our project.  Its ok to compare to
> other projects (as I often do with Struts).  In the end, however, I
> think its good to do it differently if the new direction yields a
> better result for you.
> 
Struts is not a maven2 project. Please look at the maven project.
I don't see the advantages of your direction

> I am only slight +1 for the shorter names.  So far we have 4 people in
> favor of the short names and 2 against.
> 
> 
>>What is the difference between api and myfaces-api?
> 
> 
> There is obviously a difference because 4 people favor it one way and
> 2 people favor the other way.  I favor the short name for "style"
> reasons.  You favor the short name for "IDE" reasons.
I don't favor the short name for IDE reasons. In a IDE I see the 
artifactId the long name.

   Neither reason
> is a technical one.  So I say keep the discussion open for a few more
> days and let the majority decide this one.

One description was a technical one. If myfaces grows I expect more 
directories with the same name.

> 
You don't describe any pro and cons. Everybody without a maven 
background would agree you. But many people with a maven background 
would prefer the maven conventions. Your vote is not really fair.

> 
>>Adf faces and tobago follows this convention.
> 
For me it is the best outcome.
> 
> That can be changed in a few minutes with 'svn move.'  Not a good
> reason.  We should decide on the best outcome and then either change
> myfaces to match the adf/tobago format or change adf and tobago to the
> current format.
> 
> 
>>Should they go back?
> 
> 

If you go this direction I think this is not the apache way.
I'm really disapointed you write your mail that the others without maven 
background would agree.

But I hope you get some more maven background now and you change your mind.
And please look at the structure of the maven project, maybe you 
understand me then.
> Yes if that's what the majority decides.

> 
> I look at it slightly differently.  There is only one myfaces-core and
> that is the JSR-127 implementation.  The plan is to merge ADF and
> tomahawk so there is only one subproject: tomahawk.  (That's not a
> final decision or anything, just the working consensus amongst the
> PMC.)
> 
All of adf would be tomahawk? I don't expect it. Some of the parts can 
be merge with tomahawk. I think this must be technical decision and not 
only discuss internal in the PMC.

Why this discussion is not open? Why we can't participate? What PMC 
means Technical Management Committee. Then I should ask the PMC if I 
have a technical problems instead asking the community.


Do you expect a 1.2 api from myfaces?

> There is no core for tomahawk now nor do we expect one.  If tobago
> needs a core, that's ok.  You have myfaces/tobago/trunk/core.  What's
> the problem?  IMO tobago-core is redundant if its part of tobago
> already. 
>
Is was only an example.
What is your problem with tobago-core?

> 
>>If you look at the maven repository I count 4 xyz-core dirs and 5
>>xyz-api dirs and it would be funny if each plugin has only a dir plugin
>>and not xyz-forwhat-plugin.
> 
> 
> Are you talking about the maven repository for the maven project?  I
> guess they have a different way of organizing it.  It doesn't seem any
> less confusing then our approach.  I have a working knowledge of maven
> now and at first glance the layout doesn't tell me anything useful
> about where to find the artifacts for the subprojects I need.
> 
Sorry, I'm talking about their source repository. They don't have a 
different way they implements the maven way.

> 
>>>3.) Establish a core module.  So we have myfaces/core/trunk/api and
>>>myfaces/core/trunk/impl.  Bernd and I had started down this road and
>>>stopped at his request.  I think the issues that concerned us then can
>>>be addressed now.  So can we agree to do this?
>>
>>+1
> 
> 
> Good.  We all agree on this one.  ;-)
> 
> 
>>The problem is the dependency of commons to api and the dependency of
>>impl to common. If you try to build the core you get an error the
>>dependency of commons is not found. And you can't build common without api.
> 
> 
> An excellent point. I remember this from your earlier post.
> 
> 
>>We can solve this if commons has a dependency to myfaces-api-1.1.1.jar.
>>But we should relocate the former version to the new groupId
>>org.apache.myfaces first.
> 
> 
> +1
> 
> 
>>I'm missing a discussion about the right groupId and artifactId for each
>>pom and project.
>>
>>org.apache.myfaces
>>org.apache.myfaces.tomahawk?
> 
> 
> Why not a different group id for all of the subprojects?
> 
> org.apache.myfaces.core
> org.apache.myfaces.commons
> org.apache.myfaces.tomahawk
> org.apache.myfaces.sandbox
> 
Why not, but I would prefer org.apache.myfaces for core
If sandbox depends on tomahawk it should be org.apache.myfaces.tomahawk

> 
>>myfaces-parent
> 
> 
> myfaces-maven
> 
I would prefer myfaces-parent
This is not the myfaces-maven project
I would expect it for the the maven plugins and tools in myfaces
> 
>>myfaces-project
> 
> 
> What's this?

a different suggestion for myfaces-parent
> 
> 
>>myfaces-tomahawk
>>tomahawk
> 
> 
> +1 tomahawk
> 
ok, but which name for the tomahawk master pom?
> 
>>myfaces-sandbox
>>tomahawk-sandbox
> 

> 
> sandbox
> 
the master pom of sandbox can't be sandbox because the sandbox src pom 
has already this artifactId
> 
>>myfaces-example-simple
>>tomahawk-example-simple?
> 
> 
> not sure
> 
I'm too



Bernd

Re: [maven] We need to make a decision

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

> -1
>
> We don't need a master pom at a different place. The master pom need one
> more external and must be released everytime a subproject is released.

The external does not need to be maintained so I don't think this
matters.  Yes we need to type a few lines to "release" the maven
module before releasing another module.  No big deal IMO.  (We need to
do this for commons also.)

There are other things that will go into the maven module besides the
master pom.  The archtype plugin, etc.  Those should be released
before we release the other modules also.  I don't see the difficulty
in doing this.  Maven makes it *trivial* to release.  And these
"releases" (for the maven specific artifacts) don't really have to be
tested.

> Each subproject should not have a ref to a master pom, when it has a own
> release cycle. And I expect a different groupId for tomahawk, tobago and
> adf faces in future. The master pom is not reactor aware. This means it
> can not contain the modules section.

Why not share the master pom between subprojects.  There is a *ton* of
information that needs to be shared between modules.

What does group id have to do with anything?  I tested the master pom
with a group id of org.apache.myfaces.maven and it works fine with
following in api/pom.xml

  <parent>
    <groupId>org.apache.myfaces.maven</groupId>
    <artifactId>master-pom</artifactId>
    <version>1.0.0-SNAPSHOT</version>	
  </parent>

NOTE: This is not checked in yet (tested on my local machine only)

> The master contains only the mailingLists, licenses, organization,
> ciManagement, repositories and pluginRepositories section.

Only?  That is a lot.  Why would we want to duplicate *any* of this
information *ever*?  Isn't that the whole point of maven?  It makes it
easy to build and reuse artifacts.  I'm not a maven expert (you know
more about it then I do) but according to John and Wendy this is
perfectly acceptable practice.

>
> The developers and contributors are different from subproject to subproject.

Not true.  The committers for myfaces have karma for all subprojects. 
There may be people who specialize in one subproject or another but
that doesn't matter.  The committers are the same for all projects.

We do *not* want the contributor pages to be out of sync across
subprojects.  Check out these two Struts pages for an example of how
things can go wrong.  (NOTE: Wendy will probably fix it as soon as she
sees this.)

http://struts.apache.org/team-list.html
http://struts.apache.org/struts-shale/team-list.html

> The issueManagement section is different because each subproject has a
> own project in the category myfaces(to define own releases and versions).

Not true.  There is only one project for MyFaces now.  You are right
that we might want to change this soon though.  When we do, the scm
stuff should move from the master pom to the relevant subproject.  (No
worries.)

> Please describe what a master pom should contain.
> The minimal content is not worth for an external, releasing, tagging ...

Maven should handle the tagging and releasing easily enough.  The
external is already created and doesn't have to be maintained.

> If this would be best praxis why maven has not gone this way.

I'm not sure.  I don't know much about their project.  Ultimately we
have to decide what's best for our project.  Its ok to compare to
other projects (as I often do with Struts).  In the end, however, I
think its good to do it differently if the new direction yields a
better result for you.

> -1
>
> Everyone would agree if you say: "My personal preference is to keep the
> directory name as short as possible".
>
> But you have to add a scm and a release plugin section for each pom that
> not follows this convention so far.

I need to think about the answer to this.  I don't know enough about
that aspect of maven yet.

> Is anybody not using an IDE?

I use JBuilder with no problem.  I really don't understand what kind
of IDE requires folders to match maven artifact names.  We're not
going to always be able to make things work perfect with everyone's
IDE.  We'll do our best of course, but if most people prefer a
directory name of 'api' to 'myfaces-api' and your IDE doesn't like it,
then you need to find a new IDE.

I am only slight +1 for the shorter names.  So far we have 4 people in
favor of the short names and 2 against.

> What is the difference between api and myfaces-api?

There is obviously a difference because 4 people favor it one way and
2 people favor the other way.  I favor the short name for "style"
reasons.  You favor the short name for "IDE" reasons.  Neither reason
is a technical one.  So I say keep the discussion open for a few more
days and let the majority decide this one.

> Adf faces and tobago follows this convention.

That can be changed in a few minutes with 'svn move.'  Not a good
reason.  We should decide on the best outcome and then either change
myfaces to match the adf/tobago format or change adf and tobago to the
current format.

> Should they go back?

Yes if that's what the majority decides.

> I try to explain why for example myfaces-api makes more sense.
> I expect more APIs in the myfaces universe in future. Should the
> directory name of this api or xyz-api?
> What would you prefer core, core and core or tomahawk-core, adf-core and
> tobago-core?

I look at it slightly differently.  There is only one myfaces-core and
that is the JSR-127 implementation.  The plan is to merge ADF and
tomahawk so there is only one subproject: tomahawk.  (That's not a
final decision or anything, just the working consensus amongst the
PMC.)

There is no core for tomahawk now nor do we expect one.  If tobago
needs a core, that's ok.  You have myfaces/tobago/trunk/core.  What's
the problem?  IMO tobago-core is redundant if its part of tobago
already.

> If you look at the maven repository I count 4 xyz-core dirs and 5
> xyz-api dirs and it would be funny if each plugin has only a dir plugin
> and not xyz-forwhat-plugin.

Are you talking about the maven repository for the maven project?  I
guess they have a different way of organizing it.  It doesn't seem any
less confusing then our approach.  I have a working knowledge of maven
now and at first glance the layout doesn't tell me anything useful
about where to find the artifacts for the subprojects I need.

> > 3.) Establish a core module.  So we have myfaces/core/trunk/api and
> > myfaces/core/trunk/impl.  Bernd and I had started down this road and
> > stopped at his request.  I think the issues that concerned us then can
> > be addressed now.  So can we agree to do this?
>
> +1

Good.  We all agree on this one.  ;-)

> The problem is the dependency of commons to api and the dependency of
> impl to common. If you try to build the core you get an error the
> dependency of commons is not found. And you can't build common without api.

An excellent point. I remember this from your earlier post.

> We can solve this if commons has a dependency to myfaces-api-1.1.1.jar.
> But we should relocate the former version to the new groupId
> org.apache.myfaces first.

+1

> I'm missing a discussion about the right groupId and artifactId for each
> pom and project.
>
> org.apache.myfaces
> org.apache.myfaces.tomahawk?

Why not a different group id for all of the subprojects?

org.apache.myfaces.core
org.apache.myfaces.commons
org.apache.myfaces.tomahawk
org.apache.myfaces.sandbox

> myfaces-parent

myfaces-maven

> myfaces-project

What's this?

> myfaces-tomahawk
> tomahawk

+1 tomahawk

> myfaces-sandbox
> tomahawk-sandbox

sandbox

> myfaces-example-simple
> tomahawk-example-simple?

not sure

> Bernd

Sean

Re: [maven] We need to make a decision

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

Sorry for the late answer my provider has some problems with the mailsystem.

Sean Schofield schrieb:
> OK,
> 
> We have been discussing a few important maven-related decisions these
> past few days.  Its time to make a decision and move on.  Here is my
> proposal.  I'd like to see a couple of +1's and then we can get back
> to business.  Everything is held up by this matter so lets bring it to
> a close.
> 
> 1.) Make the master pom an official artifact of myfaces.  Its a little
> weird to have a POM only artifact in the public maven repository but
> who cares?  Its not a big deal. Everything is downloaded
> automatically.  This seems to make more sense then hiding it in
> api/pom.xml (where it is now.)  The master pom is needed my all
> modules therefore its a dependency.  It could sit in myfaces/pom.xml
> except each of the modules is releasable on its own schedule so IMO
> there is no other logical alternative.

-1

We don't need a master pom at a different place. The master pom need one 
more external and must be released everytime a subproject is released.
Each subproject should not have a ref to a master pom, when it has a own 
release cycle. And I expect a different groupId for tomahawk, tobago and 
adf faces in future. The master pom is not reactor aware. This means it 
can not contain the modules section.

The master contains only the mailingLists, licenses, organization, 
ciManagement, repositories and pluginRepositories section.

The developers and contributors are different from subproject to subproject.

The issueManagement section is different because each subproject has a 
own project in the category myfaces(to define own releases and versions).

Please describe what a master pom should contain.
The minimal content is not worth for an external, releasing, tagging ...

If this would be best praxis why maven has not gone this way.


> 
> 2.) Directory names vs. artifiact names.  Bernd has suggested a
> preference for the two matching but this is definitely not a
> requirement for maven.  I propose core/trunk/api instead of
> core/trunk/myfaces-api.  There is no *technical* reason for doing this
> *either way.*  My personal preference is to keep the directory names
> as short as possible.  The final product will be call myfaces-api.jar
> either way.

-1

Everyone would agree if you say: "My personal preference is to keep the 
directory name as short as possible".

But you have to add a scm and a release plugin section for each pom that 
not follows this convention so far.
Is anybody not using an IDE?
What is the difference between api and myfaces-api?
Adf faces and tobago follows this convention.
Should they go back?

I try to explain why for example myfaces-api makes more sense.
I expect more APIs in the myfaces universe in future. Should the 
directory name of this api or xyz-api?
What would you prefer core, core and core or tomahawk-core, adf-core and 
tobago-core?

If you look at the maven repository I count 4 xyz-core dirs and 5 
xyz-api dirs and it would be funny if each plugin has only a dir plugin 
and not xyz-forwhat-plugin.

> 
> 3.) Establish a core module.  So we have myfaces/core/trunk/api and
> myfaces/core/trunk/impl.  Bernd and I had started down this road and
> stopped at his request.  I think the issues that concerned us then can
> be addressed now.  So can we agree to do this?

+1

The problem is the dependency of commons to api and the dependency of 
impl to common. If you try to build the core you get an error the 
dependency of commons is not found. And you can't build common without api.

We can solve this if commons has a dependency to myfaces-api-1.1.1.jar. 
But we should relocate the former version to the new groupId 
org.apache.myfaces first.

> 
> Keep in mind nothing is final.  We can always revisit the decision if
> we found we made a mistake.  But it will be easier to make the right
> decision the first time around.

> 
> Sean
> 

I'm missing a discussion about the right groupId and artifactId for each 
pom and project.

org.apache.myfaces
org.apache.myfaces.tomahawk?

myfaces-parent
myfaces-project
myfaces-tomahawk
tomahawk
myfaces-sandbox
tomahawk-sandbox
myfaces-example-simple
tomahawk-example-simple?




Regards


Bernd

Re: [maven] We need to make a decision

[Greg Reddin <gr...@apache.org>]

On Jan 16, 2006, at 8:22 AM, Sean Schofield wrote:

> 2.) Directory names vs. artifiact names.  Bernd has suggested a
> preference for the two matching but this is definitely not a
> requirement for maven.  I propose core/trunk/api instead of
> core/trunk/myfaces-api.  There is no *technical* reason for doing this
> *either way.*  My personal preference is to keep the directory names
> as short as possible.  The final product will be call myfaces-api.jar
> either way.

I'm using the proposed structure for a project at work and it's  
working well.  I used to have the following directory structure:

project-xyz/pom.xml - Master
project-xyz/project-xyz-core/pom.xml - produces project-xyz-core.jar
project-xyz/project-xyz-webapp1/pom.xml - produces projext-xyz- 
webapp1.war
project-xyz/project-xyz-webapp2/pom.xml - produces projext-xyz- 
webapp2.war

I refactored the directory structure to this and it is working  
beautifully:

project-xyz/pom.xml - Master
project-xyz/core/pom.xml - produces project-xyz-core.jar
project-xyz/webapp1/pom.xml - produces projext-xyz-webapp1.war
project-xyz/webapp2/pom.xml - produces projext-xyz-webapp2.war

Now the project has a very logical directory structure without a lot  
of annoying redundancy, yet the distribution artifacts are still  
named appropriately.  I think this will be a common Maven use case.   
All your subprojects are intrinsically part of the master project and  
repeating the name becomes very tiresome :-)

Greg

Re: [maven] We need to make a decision

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

> I think what Sean's "core" is meant to be is simply an "assembly"
> project, where myfaces-commons.jar, myfaces-api.jar and myfaces-impl.jar
> get bundled into a myfaces.tar.gz or myfaces.zip file.

exactly

> I don't quite know why this can't be done in the myfaces-impl.jar
> project but I guess there's some technical maven reason.

Each pom.xml builds a single artifact (at least that seems to be the
standard if not the rule.)  So you have one directory (and a matching
pom) for the api.jar, one for impl.jar and one parent directory to
bind the resulting jars for api and impl into a single tarball.

Also, if we have core/trunk/api and core/trunk/impl then when we
tag/branch we only need to create one tag/branch for both.

> This is *not* like the old "share" module which contained java classes
> that was then inserted into multiple jars; as you say that causes nasty
> issues when the jars are deployed via different classloaders. The common
> code now goes into "myfaces-commons.jar", which must be deployed *once
> only* in the classpath.
>
> There is a slight gotcha with the "myfaces-commons.jar" approach.
> Imaging someone preparing a webapp using tomahawk that may be deployed
> on a container that bundles Sun RI, or may be deployed on a container
> that bundles myfaces-commons.jar and myfaces-api.jar. If they don't
> bundle myfaces-commons.jar, then the app won't work on Sun RI. If they
> do, then on the myfaces-based container they have duplicated
> myfaces-commons.jar, and therefore (if child-first classloading is
> selected) will get the ClassCastException problem. However it's not too
> serious a problem and I can't see any better solution other than some of
> the early complicated proposals that included automated renaming of all
> the "commons" classes so they could be bundled with both impl and
> tomahawk without conflict.
>

That's a pretty good summary.  Not perfect but the best solution we have so far.

> Regards,

> Simon

Sean

Re: [maven] We need to make a decision

[John Fallows <jo...@gmail.com>]

In reality, the code in the public myfaces-commons codebase is nowhere close
to being locked down in the same way as the various Apache Commons public
APIs.

For example, it contains code in many identical packages to
myfaces-tomahawk, that needs to be fixed before this API could be considered
public.

It also contains MyfacesConfig (MyFacesConfig would be a better name?) that
provides access to some set of configuration parameters.  Why is this in
commons?  Where is the code that reacts to these configuration parameter
values?  Tomahawk?

The ResponseWriterAdapter is a good example of something that should be
included in this kind of commons API.  In fact, there should be adapters for
all the classes supporting the decorator pattern as well.  These classes are
part of the specification in JSF 1.2, emphasizing their need.

The SimpleActionMethodBinding is another good example, although I'm not
crazy about the name, perhaps FixedOutcomeMethodBinding would be more
descriptive.

The renderkit package really does need to be removed, as it is not a public
API in any way - this is simply internal implementation details that have
been promoted into a shared location to support reuse across Tomahawk and
the Runtime.  The main reason for doing this, is to support some protected
hooks that can leverage things like UserRoleUtils.isEnabledOnUserRole(...)
and UserRoleUtils.isVisibleOnUserRole(...), when EL expressions such as
rendered="#{myFaces.userRoles.role}" could have been used by the page author
instead of visibleOnUserRole="role" to achieve the desired effect without
the need for special APIs that then force the implementation internals into
a shared public API.

Similarly, the taglib package needs to be removed from myfaces-commons as
well.  In ADF Faces, we generate all our tag code during the build, so there
is no need to promote internal implementation details into a shared public
API.

This is a real issue that should be addressed *before* releasing the
myfaces-commons JAR.  Could we have a serious discussion about cleaning this
up?

Btw, no one has yet commented on whether JavaEE 5 will solve this for us for
the case where the MyFaces JSF 1.2 Runtime is on the main JavaEE Container
ClassLoader, while MyFaces JSF 1.2 Tomahawk component library is on the web
app ClassLoader.  Any thoughts?

Kind Regards,
John Fallows.

On 1/17/06, Manfred Geiler <ma...@gmail.com> wrote:
>
> 2006/1/17, Sean Schofield <se...@gmail.com>:
> > > Hmm..good point. If myfaces-commons is deployed at the container
> level,
> > > but a new version of tomahawk wants a later myfaces-commons that's a
> > > problem. It's very bad style to require a container's libs to be
> > > upgraded in order to deploy a webapp, even if the new myfaces-commons
> > > jarfile is supposed to be binary-compatible with the old one.
> >
> > Yes but its the best solution we've come up with so far.  John had
> > some ideas in a thread several weeks ago.  I'm going to go back an
> > re-read them to see if I can't understand his proposal better.
> >
> > We need to get an update release out within the next few weeks and
> > we're not likely to reach a better solution by then.
> >
> > My 2 cents,
> >
>
> Here I agree with Sean.
> We should also keep in mind that the commons classes we are speaking
> of really (should) have "commons" nature. That means: The same problem
> apply as it does for EVERY commons library. Many containers already
> use commons libraries for their own implementation. So, as a real life
> example: Tomcat is shipped with a version of commons-el.jar. Now, what
> if MyFaces needs a newer version for some reason? Should we as well
> repackage commons-el classes for our MyFaces implementation to solve
> problems before they even arise? What about all the other commons
> libs: commons-collections, commons-digester, commons-fileupload,
> commons-logging, commons-validator, ...
> And in the end we repackage (i.e. refactor) every third-party lib that
> MyFaces Impl (or Tomahawk) is using?
> You might say: But all this commons stuff is stable and almost never
> changes! Yes, they have stable APIs, but No, they are bugfixed and
> enhanced all the time. This is the path that we should strike. Come to
> a stable commons jsf API that remains compatible over the time. And if
> we fix bugs or enhance this lib: What's the problem with replacing the
> container shipped version with a new version?
> No need to overreact in this issue, IMO.
>
> Manfred
>



--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044

Re: [maven] We need to make a decision

[Manfred Geiler <ma...@gmail.com>]

2006/1/17, Sean Schofield <se...@gmail.com>:
> > Hmm..good point. If myfaces-commons is deployed at the container level,
> > but a new version of tomahawk wants a later myfaces-commons that's a
> > problem. It's very bad style to require a container's libs to be
> > upgraded in order to deploy a webapp, even if the new myfaces-commons
> > jarfile is supposed to be binary-compatible with the old one.
>
> Yes but its the best solution we've come up with so far.  John had
> some ideas in a thread several weeks ago.  I'm going to go back an
> re-read them to see if I can't understand his proposal better.
>
> We need to get an update release out within the next few weeks and
> we're not likely to reach a better solution by then.
>
> My 2 cents,
>

Here I agree with Sean.
We should also keep in mind that the commons classes we are speaking
of really (should) have "commons" nature. That means: The same problem
apply as it does for EVERY commons library. Many containers already
use commons libraries for their own implementation. So, as a real life
example: Tomcat is shipped with a version of commons-el.jar. Now, what
if MyFaces needs a newer version for some reason? Should we as well
repackage commons-el classes for our MyFaces implementation to solve
problems before they even arise? What about all the other commons
libs: commons-collections, commons-digester, commons-fileupload,
commons-logging, commons-validator, ...
And in the end we repackage (i.e. refactor) every third-party lib that
MyFaces Impl (or Tomahawk) is using?
You might say: But all this commons stuff is stable and almost never
changes! Yes, they have stable APIs, but No, they are bugfixed and
enhanced all the time. This is the path that we should strike. Come to
a stable commons jsf API that remains compatible over the time. And if
we fix bugs or enhance this lib: What's the problem with replacing the
container shipped version with a new version?
No need to overreact in this issue, IMO.

Manfred

Re: [maven] We need to make a decision

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

> Hmm..good point. If myfaces-commons is deployed at the container level,
> but a new version of tomahawk wants a later myfaces-commons that's a
> problem. It's very bad style to require a container's libs to be
> upgraded in order to deploy a webapp, even if the new myfaces-commons
> jarfile is supposed to be binary-compatible with the old one.

Yes but its the best solution we've come up with so far.  John had
some ideas in a thread several weeks ago.  I'm going to go back an
re-read them to see if I can't understand his proposal better.

We need to get an update release out within the next few weeks and
we're not likely to reach a better solution by then.

My 2 cents,

> Cheers,
>
> Simon
>
>

Sean

Re: [maven] We need to make a decision

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

On Mon, 2006-01-16 at 20:51 -0500, Mike Kienenberger wrote:
> On 1/16/06, Simon Kitching <sk...@apache.org> wrote:
> > I can't see any better solution other than some of
> > the early complicated proposals that included automated renaming of all
> > the "commons" classes so they could be bundled with both impl and
> > tomahawk without conflict.
> 
> Yes, repackaging isn't just a better solution -- it's the only solution.
> 
> Otherwise we won't be able to upgrade Tomahawk without upgrading the
> Myfaces implementation.   And at some point, we all desire for the
> myfaces-impl to finalize, while allowing tomahawk to move forward.

Hmm..good point. If myfaces-commons is deployed at the container level,
but a new version of tomahawk wants a later myfaces-commons that's a
problem. It's very bad style to require a container's libs to be
upgraded in order to deploy a webapp, even if the new myfaces-commons
jarfile is supposed to be binary-compatible with the old one.

Cheers,

Simon

Re: [maven] We need to make a decision

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

On 1/16/06, Simon Kitching <sk...@apache.org> wrote:
> I can't see any better solution other than some of
> the early complicated proposals that included automated renaming of all
> the "commons" classes so they could be bundled with both impl and
> tomahawk without conflict.

Yes, repackaging isn't just a better solution -- it's the only solution.

Otherwise we won't be able to upgrade Tomahawk without upgrading the
Myfaces implementation.   And at some point, we all desire for the
myfaces-impl to finalize, while allowing tomahawk to move forward.

myfaces-commons (was [maven] We need to make a decision)

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

On Mon, 2006-01-16 at 17:42 -0800, John Fallows wrote:
> The problem has been repackaged, but the only difference between the
> old "share" module approach and this "commons" approach is that now
> you can choose which version of the overlapping code takes precedence.

No, you can ensure that just one myfaces-commons.jar file is deployed,
thus eliminating the duplication.

> 
> Btw, what makes you say that this type of ClassCastException problem
> is "not too serious"?

The exception is serious. But fixing it is reasonably simple: delete one
of the copies of myfaces-commons.jar. This may require unpacking the war
file you're trying to deploy which is a nuisance but not impossible.

> 
> When the application developer encounters this problem, what are his
> options?
>   a) upgrade the container version of myfaces-commons.jar and hope it
> is compatible with the runtime (assuming he is allowed do this)
>   b) remove myfaces-commons.jar from his webapp and hope the container
> version is compatible
>   c) switch to using the Sun RI

Yep.

Better solutions would be very welcome I'm sure. However one that
involves having dozens classes in both the impl and tomahawk trees,
identical except for the package name, is probably not going to be
accepted due to the maintenance issues.

According to a quick count, myfaces-commons contains 87 classes. Not
something I'd be fond of maintaining two copies of.

> Anyway, my question was more along the lines of JSF 1.2, as I was
> wondering if the ClassLoaders could be arranged in the Application
> Server to avoid the two different versions of myfaces-commons.jar from
> colliding.  I don't think that Web Applications (should?) have access
> to every class used by the implementation of the Application Server,
> right?

I agree completely on this. 

I think servlet containers have got this horribly wrong, and that they
should ensure that the only thing visible to deployed webapps are the
official APIs defined in the servlet spec. And that there should be *no*
"shared lib" mechanism whatsoever; if a webapp wants library X then it
should deploy that library locally rather than in a shared location. 

Alternately, a system where containers provided "shared-api" and
"shared-impl" directories would be at least an improvement; myfaces-api
could go in the shared-api directory and be visible while
myfaces-commons and myfaces-impl could go in the shared-impl and not be
accessable from webapps.

>>From experience, however, very few people agree with me.

And it's simply not going to happen.

So for now we're stuck with trying to find a way of packaging myfaces
code to avoid the worst of the classloader-related problems while not
duplicating code between impl and tomahawk. Again, I'm sure improvements
on the current solution would be very welcome indeed.

Regards,

Simon

Re: [maven] We need to make a decision

[John Fallows <jo...@gmail.com>]

On 1/16/06, Simon Kitching <sk...@apache.org> wrote:
>
> On Mon, 2006-01-16 at 11:50 -0800, John Fallows wrote:
>
> > Sorry, I meant what is the purpose of having a core module at all?
> > (not, why is it structured in this way)
> >
> > In other words, who is going to use this module.  Why does it need to
> > exist?
>
>
> > I'll try to clarify.
>
> I think what Sean's "core" is meant to be is simply an "assembly"
> project, where myfaces-commons.jar, myfaces-api.jar and myfaces-impl.jar
> get bundled into a myfaces.tar.gz or myfaces.zip file.
>
> I don't quite know why this can't be done in the myfaces-impl.jar
> project but I guess there's some technical maven reason.


I think this is a stylistic reason rather than a technical reason.

This is *not* like the old "share" module which contained java classes
> that was then inserted into multiple jars; as you say that causes nasty
> issues when the jars are deployed via different classloaders. The common
> code now goes into "myfaces-commons.jar", which must be deployed *once
> only* in the classpath.
>
> There is a slight gotcha with the "myfaces-commons.jar" approach.
> Imaging someone preparing a webapp using tomahawk that may be deployed
> on a container that bundles Sun RI, or may be deployed on a container
> that bundles myfaces-commons.jar and myfaces-api.jar. If they don't
> bundle myfaces-commons.jar, then the app won't work on Sun RI. If they
> do, then on the myfaces-based container they have duplicated
> myfaces-commons.jar, and therefore (if child-first classloading is
> selected) will get the ClassCastException problem. However it's not too
> serious a problem and I can't see any better solution other than some of
> the early complicated proposals that included automated renaming of all
> the "commons" classes so they could be bundled with both impl and
> tomahawk without conflict.


The problem has been repackaged, but the only difference between the old
"share" module approach and this "commons" approach is that now you can
choose which version of the overlapping code takes precedence.

Btw, what makes you say that this type of ClassCastException problem is "not
too serious"?

When the application developer encounters this problem, what are his
options?
  a) upgrade the container version of myfaces-commons.jar and hope it is
compatible with the runtime (assuming he is allowed do this)
  b) remove myfaces-commons.jar from his webapp and hope the container
version is compatible
  c) switch to using the Sun RI

Anyway, my question was more along the lines of JSF 1.2, as I was wondering
if the ClassLoaders could be arranged in the Application Server to avoid the
two different versions of myfaces-commons.jar from colliding.  I don't think
that Web Applications (should?) have access to every class used by the
implementation of the Application Server, right?

Kind Regards,
John Fallows.

--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044

Re: [maven] We need to make a decision

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

On Mon, 2006-01-16 at 11:50 -0800, John Fallows wrote:

> Sorry, I meant what is the purpose of having a core module at all?
> (not, why is it structured in this way)
> 
> In other words, who is going to use this module.  Why does it need to
> exist?


> I'll try to clarify.

I think what Sean's "core" is meant to be is simply an "assembly"
project, where myfaces-commons.jar, myfaces-api.jar and myfaces-impl.jar
get bundled into a myfaces.tar.gz or myfaces.zip file. 

I don't quite know why this can't be done in the myfaces-impl.jar
project but I guess there's some technical maven reason.

This is *not* like the old "share" module which contained java classes
that was then inserted into multiple jars; as you say that causes nasty
issues when the jars are deployed via different classloaders. The common
code now goes into "myfaces-commons.jar", which must be deployed *once
only* in the classpath. 

There is a slight gotcha with the "myfaces-commons.jar" approach.
Imaging someone preparing a webapp using tomahawk that may be deployed
on a container that bundles Sun RI, or may be deployed on a container
that bundles myfaces-commons.jar and myfaces-api.jar. If they don't
bundle myfaces-commons.jar, then the app won't work on Sun RI. If they
do, then on the myfaces-based container they have duplicated
myfaces-commons.jar, and therefore (if child-first classloading is
selected) will get the ClassCastException problem. However it's not too
serious a problem and I can't see any better solution other than some of
the early complicated proposals that included automated renaming of all
the "commons" classes so they could be bundled with both impl and
tomahawk without conflict.

Regards,

Simon

Re: [maven] We need to make a decision

[John Fallows <jo...@gmail.com>]

On 1/16/06, Sean Schofield <se...@gmail.com> wrote:
>
> >  I know it sounds weird at first, but having a POM dependency is not
> that
> > strange in the land of Maven. :-)
>
> OK I think we have general agreement on this.  @Bernd: We can always
> change this approach later if it doesn't work out.
>
> >  I agree with Bernd, my preference would be for these to match as well.
> >
> >  When you svn checkout with TortoiseSVN, the local directory name
> defaults
> > to the last part of the checkout path.
> >
> >  So, if folks are checking out just "api", then there's not enough
> context
> > in the "api" name for their default local directory name.
>
> This is easily fixed by checking out to myfaces-api instead of api.  I
> think the most common use case is to checkout out "current" to
> "myfaces" in which case you will have the myfaces parent directory.


Or, in the case of the default naming scheme, the local directory will be
called "current".

>  Similarly, if folks are checking out trunk, and leave the default name
> > "trunk" for the local directory, then subdirectories of "api", "impl",
> etc
> > do not provide sufficient context.  I've seen this "trunk" checkout
> > technique many times among my colleagues, especially as they were
> starting
> > out with SVN.
> >
> >  ADF Faces uses the following directory structure:
> >
> >    trunk/
> >      pom.xml
> >      adf-faces-api/
> >      adf-faces-impl/
> >      adf-faces-demo/
> >      adf-faces-build/
>
> Most seem to prefer the shorter names so I think we should leave them
> as short names for now.  Since the short names do not affect what goes
> into the maven repo there is no harm in doing an svn change later it
> we want to.


Okay, maybe we can revisit this later, although I did like your idea of
getting it right the first time. :-)

>  Note: this last module, "adf-faces-build" contains metadata that is used
> at
> > build time, so it's a little different from the "build" module in
> MyFaces.
>
> Would this be the same as my proposed myfaces-master?


No.  This is just for metadata used during the build, and we have our
cross-module pom.xml sitting above "adf-faces-api", "adf-faces-impl", etc,
as shown in the directory listing for trunk above.

This would be
> where the master pom lives.  Also, because each module could
> potentially be on its own release track, we can't really have a
> meaningful top level pom (myfaces/pom.xml).  Continuum is going to
> build everything for us anyways so big deal.


Without the master pom.xml, you'll get lots of fine-grained build messages
from Continuum, one per module.  The ADF Faces Continuum build uses the
master pom.xml to avoid this problem, and to prevent ongoing attempts to
build adf-faces-impl when adf-faces-api is broken, for example.

Perhaps users could keep
> a myfaces/pom.xml in their own *local* checkout dir and we can add it
> to SVN ignore.  This was you can do 'mvn install' on myfaces/pom.xml
> and build everything real quick.


That could work, although it's extra hassle to setup per developer.
What's the downside of having a bare bones pom.xml with a <modules>
defintion under myfaces/current?

> > 3.) Establish a core module.  So we have myfaces/core/trunk/api and
> > > myfaces/core/trunk/impl.  Bernd and I had started down this road and
> > > stopped at his request.  I think the issues that concerned us then can
> > > be addressed now.  So can we agree to do this?
> >
> >  What is the purpose of having such a core module?
>
> Because it will include both api and impl.  We need two separate jars
> yet they will always be released together.  So we have
> myfaces/core/trunk/api and myfaces/core/trunk/impl instead of
> myfaces/api/trunk and myfaces/impl/trunk.  Tagging and branching is
> also simplified.  Finally, we can have a myfaces/core/assembly which
> assembles everything into a single tarball.  Since the final release
> product needs to contain both, this seems to make the most sense.


Sorry, I meant what is the purpose of having a core module at all?
(not, why is it structured in this way)

In other words, who is going to use this module.  Why does it need to exist?

>  I would be concerned about releasing code in the same package for both
> the
> > runtime and the component libraries, where each is versioned and
> released
> > independently.
> >
> >  Upgrading to a new version of a component library needs to guarantee
> zero
> > impact on the runtime and having code in overlapping packages violates
> that
> > principle when both are executed in the context of the same ClassLoader,
> as
> > only one copy of the overlapping packages can take precedence.
> >
> >  Does this problem get any better or worse in JavaEE 5, where the
> container
> > is required to include a JSF 1.2 implementation?  Would the ClassLoader
> of
> > the JSF 1.2 implementation be sufficiently isolated from the ClassLoader
> of
> > each Web Application to not be impacted by having two versions of the
> > overlapping packages?
>
> Not sure what you mean by this.  Hopefully my explanation of core will
> address your concerns.  If not, please clarify.


The explanation of core was informative but unrelated to this point.

I'll try to clarify.

We all know how ClassLoaders work, right?  All the JARs are on the ClassPath
in a particular order, and each Class is accessed by a relative path, eg.
org/apache/myfaces/application/NavigationHandlerImpl.class.  Usually, due to
cooperation between code authors to separate their Classes into different
Packages, there are no duplicate entries on the ClassPath for the same
relative path.  When there are such duplicate entries for the same relative
path, then only one will be visible to the ClassLoader, based on the order
of the JARs on the ClassPath.

When MyFaces 1.1.x Runtime and MyFaces 1.1.x Tomahawk are both deployed as
part of the same Web Application, then their classes will be accessed via
the same ClassLoader, so if they have duplicate entries on the ClassPath for
the same relative path, then only one of these duplicate entries will be
visible to the ClassLoader.  If both MyFaces 1.1.x Runtime and MyFaces
1.1.xTomahawk contain identical overlapping code, then it doesn't
matter which
one is visible to the ClassLoader, as there will be no difference in
behavior.

However, if MyFaces Tomahawk is upgraded to 1.1.x+1 then any changes to the
overlapping code may or may not be picked up by the Web Application
ClassLoader, depending on the ordering of MyFaces 1.1.x Runtime vs. MyFaces
1.1.x+1 Tomahawk.  To make matters worse, the ClassPath ordering of JARs
from WEB-INF/lib is unspecified, so there is no way to enforce a particular
precedence.

So, in order to avoid this problem, we are forced to upgrade MyFaces
1.1.x+1Runtime and MyFaces
1.1.x+1 Tomahawk in unison.  Hopefully the developer is willing and able to
upgrade MyFaces 1.1.x+1 Runtime as well, assuming there are no new bugs or
changes in behavior that would negatively impact his Web Application.

When it comes to JavaEE 5, where JSF 1.2 is a required part of the
container, I wonder if the JSF 1.2 implementation is on a ClassLoader that
is isolated from the Web Application ClassLoader.  If so, then it should be
possible to have MyFaces 1.2.x Runtime on the JavaEE Container ClassLoader,
and MyFaces 1.2.x Tomahawk on the Web Application ClassLoader, so that they
would no longer collide despite having overlapping code, and could therefore
be upgraded independently without impacting each other.

Can anyone confirm whether or not this analysis is correct?

Kind Regards,
John Fallows.

--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044

Re: [maven] We need to make a decision

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

Sean Schofield schrieb:
>> I know it sounds weird at first, but having a POM dependency is not that
>>strange in the land of Maven. :-)
> 
> 
> OK I think we have general agreement on this.  @Bernd: We can always
> change this approach later if it doesn't work out.

I hope we change it before we are performing a release :-)
It should work but I don't like it. It doesn't help really.
But we can change it later,

Bernd

Re: [maven] We need to make a decision

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

>  I know it sounds weird at first, but having a POM dependency is not that
> strange in the land of Maven. :-)

OK I think we have general agreement on this.  @Bernd: We can always
change this approach later if it doesn't work out.

>  I agree with Bernd, my preference would be for these to match as well.
>
>  When you svn checkout with TortoiseSVN, the local directory name defaults
> to the last part of the checkout path.
>
>  So, if folks are checking out just "api", then there's not enough context
> in the "api" name for their default local directory name.

This is easily fixed by checking out to myfaces-api instead of api.  I
think the most common use case is to checkout out "current" to
"myfaces" in which case you will have the myfaces parent directory.

>  Similarly, if folks are checking out trunk, and leave the default name
> "trunk" for the local directory, then subdirectories of "api", "impl", etc
> do not provide sufficient context.  I've seen this "trunk" checkout
> technique many times among my colleagues, especially as they were starting
> out with SVN.
>
>  ADF Faces uses the following directory structure:
>
>    trunk/
>      pom.xml
>      adf-faces-api/
>      adf-faces-impl/
>      adf-faces-demo/
>      adf-faces-build/

Most seem to prefer the shorter names so I think we should leave them
as short names for now.  Since the short names do not affect what goes
into the maven repo there is no harm in doing an svn change later it
we want to.

>  Note: this last module, "adf-faces-build" contains metadata that is used at
> build time, so it's a little different from the "build" module in MyFaces.

Would this be the same as my proposed myfaces-master?  This would be
where the master pom lives.  Also, because each module could
potentially be on its own release track, we can't really have a
meaningful top level pom (myfaces/pom.xml).  Continuum is going to
build everything for us anyways so big deal.  Perhaps users could keep
a myfaces/pom.xml in their own *local* checkout dir and we can add it
to SVN ignore.  This was you can do 'mvn install' on myfaces/pom.xml
and build everything real quick.

> > 3.) Establish a core module.  So we have myfaces/core/trunk/api and
> > myfaces/core/trunk/impl.  Bernd and I had started down this road and
> > stopped at his request.  I think the issues that concerned us then can
> > be addressed now.  So can we agree to do this?
>
>  What is the purpose of having such a core module?

Because it will include both api and impl.  We need two separate jars
yet they will always be released together.  So we have
myfaces/core/trunk/api and myfaces/core/trunk/impl instead of
myfaces/api/trunk and myfaces/impl/trunk.  Tagging and branching is
also simplified.  Finally, we can have a myfaces/core/assembly which
assembles everything into a single tarball.  Since the final release
product needs to contain both, this seems to make the most sense.

>  I would be concerned about releasing code in the same package for both the
> runtime and the component libraries, where each is versioned and released
> independently.
>
>  Upgrading to a new version of a component library needs to guarantee zero
> impact on the runtime and having code in overlapping packages violates that
> principle when both are executed in the context of the same ClassLoader, as
> only one copy of the overlapping packages can take precedence.
>
>  Does this problem get any better or worse in JavaEE 5, where the container
> is required to include a JSF 1.2 implementation?  Would the ClassLoader of
> the JSF 1.2 implementation be sufficiently isolated from the ClassLoader of
> each Web Application to not be impacted by having two versions of the
> overlapping packages?

Not sure what you mean by this.  Hopefully my explanation of core will
address your concerns.  If not, please clarify.

> Kind Regards,
>  John Fallows.

Sean

Re: [maven] We need to make a decision

[John Fallows <jo...@gmail.com>]

On 1/16/06, Sean Schofield <se...@gmail.com> wrote:
>
> OK,
>
> We have been discussing a few important maven-related decisions these
> past few days.  Its time to make a decision and move on.  Here is my
> proposal.  I'd like to see a couple of +1's and then we can get back
> to business.  Everything is held up by this matter so lets bring it to
> a close.
>
> 1.) Make the master pom an official artifact of myfaces.  Its a little
> weird to have a POM only artifact in the public maven repository but
> who cares?  Its not a big deal. Everything is downloaded
> automatically.  This seems to make more sense then hiding it in
> api/pom.xml (where it is now.)  The master pom is needed my all
> modules therefore its a dependency.  It could sit in myfaces/pom.xml
> except each of the modules is releasable on its own schedule so IMO
> there is no other logical alternative.


I know it sounds weird at first, but having a POM dependency is not that
strange in the land of Maven. :-)

2.) Directory names vs. artifiact names.  Bernd has suggested a
> preference for the two matching but this is definitely not a
> requirement for maven.  I propose core/trunk/api instead of
> core/trunk/myfaces-api.  There is no *technical* reason for doing this
> *either way.*  My personal preference is to keep the directory names
> as short as possible.  The final product will be call myfaces-api.jar
> either way.


I agree with Bernd, my preference would be for these to match as well.

When you svn checkout with TortoiseSVN, the local directory name defaults to
the last part of the checkout path.

So, if folks are checking out just "api", then there's not enough context in
the "api" name for their default local directory name.

Similarly, if folks are checking out trunk, and leave the default name
"trunk" for the local directory, then subdirectories of "api", "impl", etc
do not provide sufficient context.  I've seen this "trunk" checkout
technique many times among my colleagues, especially as they were starting
out with SVN.

ADF Faces uses the following directory structure:

  trunk/
    pom.xml
    adf-faces-api/
    adf-faces-impl/
    adf-faces-demo/
    adf-faces-build/


Note: this last module, "adf-faces-build" contains metadata that is used at
build time, so it's a little different from the "build" module in MyFaces.

3.) Establish a core module.  So we have myfaces/core/trunk/api and
> myfaces/core/trunk/impl.  Bernd and I had started down this road and
> stopped at his request.  I think the issues that concerned us then can
> be addressed now.  So can we agree to do this?


What is the purpose of having such a core module?

I would be concerned about releasing code in the same package for both the
runtime and the component libraries, where each is versioned and released
independently.

Upgrading to a new version of a component library needs to guarantee zero
impact on the runtime and having code in overlapping packages violates that
principle when both are executed in the context of the same ClassLoader, as
only one copy of the overlapping packages can take precedence.

Does this problem get any better or worse in JavaEE 5, where the container
is required to include a JSF 1.2 implementation?  Would the ClassLoader of
the JSF 1.2 implementation be sufficiently isolated from the ClassLoader of
each Web Application to not be impacted by having two versions of the
overlapping packages?

Kind Regards,
John Fallows.

--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044

Re: [maven] We need to make a decision

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

Sorry I've been quite, my HD died on Wednesday and I'm just getting back on line...
 
On Monday, January 16, 2006, at 09:23AM, Sean Schofield <se...@gmail.com> wrote:

>OK,
>
>We have been discussing a few important maven-related decisions these
>past few days.  Its time to make a decision and move on.  Here is my
>proposal.  I'd like to see a couple of +1's and then we can get back
>to business.  Everything is held up by this matter so lets bring it to
>a close.
>
>1.) Make the master pom an official artifact of myfaces.  Its a little
>weird to have a POM only artifact in the public maven repository but
>who cares?  Its not a big deal. Everything is downloaded
>automatically.  This seems to make more sense then hiding it in
>api/pom.xml (where it is now.)  The master pom is needed my all
>modules therefore its a dependency.  It could sit in myfaces/pom.xml
>except each of the modules is releasable on its own schedule so IMO
>there is no other logical alternative.
>

+1 on a master pom, location is not that important to me, myfaces/pom.xml sounds good to me

>2.) Directory names vs. artifiact names.  Bernd has suggested a
>preference for the two matching but this is definitely not a
>requirement for maven.  I propose core/trunk/api instead of
>core/trunk/myfaces-api.  There is no *technical* reason for doing this
>*either way.*  My personal preference is to keep the directory names
>as short as possible.  The final product will be call myfaces-api.jar
>either way.
>

+1 on shorter names

>3.) Establish a core module.  So we have myfaces/core/trunk/api and
>myfaces/core/trunk/impl.  Bernd and I had started down this road and
>stopped at his request.  I think the issues that concerned us then can
>be addressed now.  So can we agree to do this?
>

+1

>Keep in mind nothing is final.  We can always revisit the decision if
>we found we made a mistake.  But it will be easier to make the right
>decision the first time around.
>
>Sean
>
>

Re: [maven] We need to make a decision

[Mathias Brökelmann <mb...@googlemail.com>]

Thanks for the answer. I think something like myfaces-all would be
very handy too. Will we support this in the future?

2006/1/16, Sean Schofield <se...@gmail.com>:
> > I´m quite new to maven so this question may get answered by reading
> > the maven docs but does anyone know how we will get a release archive
> > structure like the latest 1.1.1?
>
> Do you mean the tarballs like myfaces-1.1.1.tar.gz?  If so, then the
> answer is with the assembly pom (still in progress.)  The releases
> will look slightly different now that we are releasing on separate
> tracks.
>
> myfaces-core-1.1.2.tar.gz (includes myfaces-api-1.1.2.jar,
> myfaces-impl-1.1.2.jar and the appropriate myfaces-commons.jar)
>
> myfaces-tomahawk-1.1.2.tar.gz (includes tomahawk-1.1.2.jar and the
> appropriate myfaces-commons.jar)
>
> Commons and the master pom technically are released but they aren't
> available as bundles and they aren't part of the release announcements
> since they are only needed to make core or tomahawk work and those
> releases will ship with the appropriate version.  (Also tobago)
>
>
> > Mathias
>
> Sean
>


--
Mathias

Re: [maven] We need to make a decision

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

> I´m quite new to maven so this question may get answered by reading
> the maven docs but does anyone know how we will get a release archive
> structure like the latest 1.1.1?

Do you mean the tarballs like myfaces-1.1.1.tar.gz?  If so, then the
answer is with the assembly pom (still in progress.)  The releases
will look slightly different now that we are releasing on separate
tracks.

myfaces-core-1.1.2.tar.gz (includes myfaces-api-1.1.2.jar,
myfaces-impl-1.1.2.jar and the appropriate myfaces-commons.jar)

myfaces-tomahawk-1.1.2.tar.gz (includes tomahawk-1.1.2.jar and the
appropriate myfaces-commons.jar)

Commons and the master pom technically are released but they aren't
available as bundles and they aren't part of the release announcements
since they are only needed to make core or tomahawk work and those
releases will ship with the appropriate version.  (Also tobago)


> Mathias

Sean

Re: [maven] We need to make a decision

[Mathias Brökelmann <mb...@googlemail.com>]

> 1.) Make the master pom an official artifact of myfaces.

+1,

> 2.) Directory names vs. artifiact names.

+1 for short names,

> 3.) Establish a core module.

+1

I´m quite new to maven so this question may get answered by reading
the maven docs but does anyone know how we will get a release archive
structure like the latest 1.1.1?

--
Mathias

Re: [maven] We need to make a decision

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

> :)  It's supposed to be there.  Remember when you uploaded just the
> jars to dist/java-repository?  They synced to the m2 repo with the
> minimal, automatically generated poms.

Not the myfaces-parent though.  That was experimental and only in the
nightly snapshot for a few minutes.

> At that point people started opening MEV tickets and submitting
> patches to add the dependencies.  Search the users@maven list for some
> fun threads while we sorted things out.  IIRC Matt Raible did a lot of
> it.  Carlos Sanchez created that myfaces-parent pom and linked up the
> others as best we could figure things out.
>
> They do need to be cleaned up, and that can be part of the
> 'relocation' TODO that's on the Wiki page.  You can either submit
> patches, or else put good poms in the Apache Maven repository and ask
> the Maven team to delete the ones on their side so the good ones will
> sync over.

Sounds like a plan.


> Wendy

Sean

Re: [maven] We need to make a decision

[Wendy Smoak <ws...@gmail.com>]

On 1/16/06, Sean Schofield <se...@gmail.com> wrote:

> > +1, and FWIW you have one already:
> >    http://www.ibiblio.org/maven2/myfaces/myfaces-parent/1.1.1/
>
> Grrr.  I don't know how these temporary artifacts are making it out to
> ibiblio.  Is there any easy way to get them cleaned up?

:)  It's supposed to be there.  Remember when you uploaded just the
jars to dist/java-repository?  They synced to the m2 repo with the
minimal, automatically generated poms.

At that point people started opening MEV tickets and submitting
patches to add the dependencies.  Search the users@maven list for some
fun threads while we sorted things out.  IIRC Matt Raible did a lot of
it.  Carlos Sanchez created that myfaces-parent pom and linked up the
others as best we could figure things out.

They do need to be cleaned up, and that can be part of the
'relocation' TODO that's on the Wiki page.  You can either submit
patches, or else put good poms in the Apache Maven repository and ask
the Maven team to delete the ones on their side so the good ones will
sync over.

--
Wendy

Re: [maven] We need to make a decision

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

> +1, and FWIW you have one already:
>    http://www.ibiblio.org/maven2/myfaces/myfaces-parent/1.1.1/

Grrr.  I don't know how these temporary artifacts are making it out to
ibiblio.  Is there any easy way to get them cleaned up?

> Wendy

Sean

Re: [maven] We need to make a decision

[Wendy Smoak <ws...@gmail.com>]

On 1/16/06, Sean Schofield <se...@gmail.com> wrote:

> 1.) Make the master pom an official artifact of myfaces.  Its a little
> weird to have a POM only artifact in the public maven repository but
> who cares?  Its not a big deal.

+1, and FWIW you have one already:
   http://www.ibiblio.org/maven2/myfaces/myfaces-parent/1.1.1/

--
Wendy

Re: [maven] We need to make a decision

[Manfred Geiler <ma...@gmail.com>]

> 1.) Make the master pom an official artifact of myfaces.  Its a little
> weird to have a POM only artifact in the public maven repository but
> who cares?  Its not a big deal. Everything is downloaded
> automatically.  This seems to make more sense then hiding it in
> api/pom.xml (where it is now.)  The master pom is needed my all
> modules therefore its a dependency.  It could sit in myfaces/pom.xml
> except each of the modules is releasable on its own schedule so IMO
> there is no other logical alternative.

Although I am (still) an absolute Maven dummy, this sounds reasonable to me:
+1


> 2.) Directory names vs. artifiact names.  Bernd has suggested a
> preference for the two matching but this is definitely not a
> requirement for maven.  I propose core/trunk/api instead of
> core/trunk/myfaces-api.  There is no *technical* reason for doing this
> *either way.*  My personal preference is to keep the directory names
> as short as possible.  The final product will be call myfaces-api.jar
> either way.

+0.1 for short dirs


> 3.) Establish a core module.  So we have myfaces/core/trunk/api and
> myfaces/core/trunk/impl.  Bernd and I had started down this road and
> stopped at his request.  I think the issues that concerned us then can
> be addressed now.  So can we agree to do this?

This is the module to hold everthing we called shared sources in the
past, right?
Then +1 from my side.


Sean et al., thanks very much for all your hard mavenizing work!

Manfred