Skip to main content

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

  • From: Martin Scott Nicklous < >
  • To:
  • Cc: , Harold Ogle < >, Bill Shannon < >, Reza Rahman < >, Arun Gupta < >
  • Subject: [jsr362-observers:] [jsr362-experts:] Re: pom.xml
  • Date: Thu, 8 Aug 2013 16:16:48 +0200
  • List-id: <jsr362-experts.portletspec3.java.net>

thanks for the info. that's pretty ugly - two separate versions of the
Portlet API v2.0 in the maven repository.

So far, I haven't been able to determine how they both came to be in
existence. I wonder where the version with groupId = "javax.portlet" came
from, and who has the source code for it. I don't, unless the source
happens to be the same as the version from the Apache Portals project.

Some months ago when the project began I verified that  the source from the
Apache Portals SVN repository matches the original IBM internal source. In
other words, the version at the Apache site below is the official version:

http://svn.apache.org/repos/asf/portals/portlet-spec/tags/portlet-api_2.0_spec-1.0

And the pom.xml available there contains the "org.apache.portals" groupId.

The source code is not contained in the "javax.portlet" version from the
mvnrepository site, so I can't effectively compare the two versions.

I would like to also point out that the groupId in the maven pom.xml file
used to build the API jar and apidocs HTML files has not been subject to
standardization (maybe it should be, but that's a different question). The
actual java source code defining the interface and containing the javadoc
comments that compose the HTML apidocs is part of the standardization
package. These source files for the Portlet Specification 2.0 code are
found in the above-mentioned SVN repository at Apache.

That said, using "javax.portlet" as groupId in the maven pom.xml does have
a certain logic to it, and I wouldn't have a problem with switching the
groupId as long as that would be agreeable to Apache. I think maven allows
you to override the parent groupId in a subproject, so the groupId could be
changed for the API code alone.

 So one question would be whether we could host the API code on Apache
using a maven groupId of "javax.portlet".

Another question would be whether the JCP PMO will provide or has provided
guidance as to the choice of groupId in the maven pom.xml file for JSR
interface code. It would probably be reasonable for all JSRs to define
their groupIds in their pom.xml files in a similar manner (providing they
even use maven - I don't believe that use of maven is strictly required),
but such guidance would have to come from the PMO.

I would be highly interested in the results of such deliberations, although
I would prefer not to participate in said deliberations, unless my
contributions would be deemed essential. :-)

So, respectfully, I think it would be good if further PMO & EC discussion
of this topic would not include the JSR362-experts mailing list on copy.

thanks,
Scott


Werner Keil 
< >
 wrote on 08.08.2013 12:21:42:

> From: Werner Keil 
> < >
> To: 
>  ,
> Cc: 
>  ,
>  Harold Ogle 
> < >,
>  Bill Shannon
> < >,
>  Reza Rahman 
> < >,
> Arun Gupta 
> < >
> Date: 08.08.13 12:22
> Subject: [jsr362-experts:] Re: pom.xml
>
> Also looping in PMO and Bill as well as Reza and Arun, since they
> are involved with EE Evangelism and technical stuff.
> E.g. for the EE 7 Umbrella, Reza put this together
> http://java.dzone.com/articles/java-ee-7-maven-repository-0
>
> and a number of Java EE 7 EG Members complained about an almost
> Kafkaesque maze finding the right components of an otherwise unified
> EE 7 "Umbrella".
>
> If you search MavenCentral for "portlet" you find 2 artifacts (aside
> from various copies and repackaged forms by SpringSource/Pivotal,
> etc.) let's just focus on the one you mentioned:
>
http://mvnrepository.com/artifact/org.apache.portals/portlet-api_2.0_spec/1.0
> which is used by a single company in Germany and
> http://mvnrepository.com/artifact/javax.portlet/portlet-api/2.0
> which is used by over a hundred or more projects, including GateIn a
> joint project driven by at least 2 EG members here, too. Or Liferay,
> Vaadin or uPortal driven by EG Members of JSR 107. And Pluto
> itself!![image removed]
> http://mvnrepository.com/artifact/org.apache.pluto/pluto-container/1.1.7
>
> So I hope there is an opinion on that by those using either of these
> artifacts which they prefer, or PMO/Oracle can help us with some
> guidance to how they'd like to see it for Java EE 8 and other nearby
JSRs.
>
> As mentioned and criticized by those having to use them, the groupId
> is quite a mess among most Java EE 7 artifacts. Closest to what you
> proposed could be
> <dependency>
>   <groupId>org.eclipse.persistence</groupId>
>     <artifactId>javax.persistence</artifactId>
>     <version>2.1.0</version>
> </dependency>
> for JPA. Which is developed and hosted at Eclipse, similar to what
> Apache might end up doing again here.
>
> Most other Java EE JSRs do have at least "javax" or
> "javax.<specname>" as groupId. So given Pluto has always used the
> "javax.portlet" form as it seems, should we have one here for Spec
> purposes and then force somebody else to repackage and -deploy it?
> [image removed]
>
> Cheers,
> Werner
>
> On Thu, Aug 8, 2013 at 11:25 AM, Martin Scott Nicklous <
>  >
>  wrote:
> The JSR 286 API is hosted on Apache at:
> http://svn.apache.org/repos/asf/portals/portlet-spec/tags/portlet-
> api_2.0_spec-1.0
>
> the pom from that repo contains:
>
> =====
>   <parent>
>     <groupId>org.apache.portals</groupId>
>     <artifactId>portals-pom</artifactId>
>     <version>1.2</version>
>   </parent>
>
>   <modelVersion>4.0.0</modelVersion>
>   <artifactId>portlet-api_2.0_spec</artifactId>
>   <version>1.0</version>
>   <packaging>bundle</packaging>
>   <name>Java Portlet Specification V2.0</name>
>   <description>The Java Portlet API version 2.0 developed by the Java
> Community Process JSR-286 Expert Group.</description>
> =====
>
> I modified the pom to remove the parent reference to make it build
> stand-alone and changed the artifact ID to refer to version 3.0.
>
> Since v3.0 will be hosted on Apache as well, I don't think we want to
> change the groupID to javax.portlet. We can talk about the artifactID and
> version. The following might be better:
>
> =====
>   <groupId>org.apache.portals</groupId>
>   <artifactId>portlet-api-spec</artifactId>
>   <version>3.0-snapshot</version>
>   <name>Java Portlet Specification V3.0</name>
>   <description>The Java Portlet API version 3.0 developed by the Java
> Community Process JSR-362 Expert Group.</description>
> =====
>
> opinions / ideas?
>
> regards,
> Scott
>
>
> Werner Keil 
> < >
>  wrote on 07.08.2013 18:47:07:
>
> > From: Werner Keil 
> > < >
> > To: 
> >  ,
> > Date: 07.08.13 18:47
> > Subject: [jsr362-experts:] Re: pom.xml
> >
> > Most importantly, shouldn't the POM be consistent with Portlet 1.0
> > and 2.0 like this
> >
> > <groupId>javax.portlet</groupId>
> > <modelVersion>4.0.0</modelVersion>
> > <artifactId>portlet-api</artifactId>
> > <version>3.0-SNAPSHOT</version>
> > <packaging>jar</packaging>
> > <name>Portlet 3.0 API</name>
> >
> > rather than
> >
> >  <groupId>org.apache.portals</groupId>
> >   <artifactId>portlet-api_3.0_spec</artifactId>
> >
>
> >   <version>0.1-SNAPSHOT</version>
> >
> >
> > If we started with 0.1-SNAPSHOT, that sounded fair, eventually there
> > should be a 3,0 in the version number and I'd expect the
> > javax.portlet group and portlet-api artifactId must remain as they
were.
> >
> > org.apache.portals could be group of a <parent> POM if such exists,
> > but not replace javax.portlet I'd say.
> >
> > Werner
>
> > On Wed, Aug 7, 2013 at 4:48 PM, Werner Keil 
> > < >
> wrote:
> > If we depend on everything that's in there, I'd say so, but as
> > mentioned, a few of the ingredients themselves do NOT require EE 7
> > or SE 7 as a minimum dependency, hence they also deviate while the
> > "entire system" doesn't.
> >



[jsr362-observers:] [jsr362-experts:] pom.xml

David S Taylor 08/03/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Martin Scott Nicklous 08/04/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Edward Burns 08/07/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Werner Keil 08/07/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Neil Griffin 08/07/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Werner Keil 08/07/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Werner Keil 08/07/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Martin Scott Nicklous 08/08/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Werner Keil 08/08/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Martin Scott Nicklous 08/08/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Werner Keil 08/08/2013

[jsr362-observers:] [jsr362-experts:] Re: pom.xml

Martin Scott Nicklous 08/08/2013
 
 
Close
loading
Please Confirm
Close