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
