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