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
