Skip to main content

[jsr362-experts:] Re: pom.xml

  • From: Werner Keil < >
  • To:
  • Subject: [jsr362-experts:] Re: pom.xml
  • Date: Thu, 8 Aug 2013 16:30:18 +0200

Well in the most recent Pluto version (1.1.7) you can find on MavenCentral
so far, it uses javax.portlet already:
http://repo1.maven.org/maven2/org/apache/pluto/pluto-container/1.1.7/pluto-container-1.1.7.pom

Code base for a Pluto 2 which at least has never gone to Maven (instead you
may download it from Apache.org) suggests, there could be the other form
used, but then again, so many other projects use it in their most recent
version, too, see the BOM (kind of a "super-POM" used by all major Red Hat
projects now[?]) for GateIn
https://github.com/gatein/gatein-bom/blob/master/pom.xml

Whoever put it there at least needs to have permission to publish to
MavenCentral. Normally that is the Spec Lead, but for large projects
somebody else, most likely at Apache[?] must have done that. SonaType
probably knows the deployment history, I don't think a POM or other details
from the outside would tell you who uploaded an artifact.

Werner

On Thu, Aug 8, 2013 at 4:16 PM, Martin Scott Nicklous <
>
 wrote:

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

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



[jsr362-experts:] pom.xml

David S Taylor 08/03/2013

[jsr362-experts:] Re: pom.xml

Martin Scott Nicklous 08/04/2013

[jsr362-experts:] Re: pom.xml

Edward Burns 08/07/2013

[jsr362-experts:] Re: pom.xml

Werner Keil 08/07/2013

[jsr362-experts:] Re: pom.xml

Neil Griffin 08/07/2013

[jsr362-experts:] Re: pom.xml

Werner Keil 08/07/2013

[jsr362-experts:] Re: pom.xml

Werner Keil 08/07/2013

[jsr362-experts:] Re: pom.xml

Martin Scott Nicklous 08/08/2013

[jsr362-experts:] Re: pom.xml

Werner Keil 08/08/2013

[jsr362-experts:] Re: pom.xml

Martin Scott Nicklous 08/08/2013

[jsr362-experts:] Re: pom.xml

Werner Keil 08/08/2013

[jsr362-experts:] Re: pom.xml

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