Hi Woonsan,

OK, I will rollback and re-release with the header present in the following 
files:

- pom.xml
- src/main/resources/META-INF/maven/archetype-metadata.xml
- src/main/resources/META-INF/maven/archetype.xml

Additionally, I will move from the Log4J API to the SLF4J API.

Would it be OK if I specify "org.slf4j:slf4j-log4j12" as the logging 
implementation?

Also, if I complete the work today, then will it require a new 72 hour voting 
process?


Thank you,

Neil

On 4/25/17 11:36 AM, Woonsan Ko wrote:
On Tue, Apr 25, 2017 at 11:09 AM, Neil Griffin
<neil.grif...@portletfaces.org> wrote:
Hi Woonsan,

I don't think that I have the administrative privileges to fix the staging
repository visibility problem you encountered.

But thank you for your careful observations. Regarding the licensing, the
Apache 2.0 License is specified in the pom.xml descriptor of each archetype:

          <license>
              <name>Apache License, Version 2.0</name>
              <url>http://www.apache.org/licenses/LICENSE-2.0</url>
          </license>

Also, the archetype JAR artifacts contain the text of the Apache 2.0 License
in the META-INF/LICENSE file.

The reason why license "headers" are not present in files like
HelloWorldPortlet.java is because archetype files are essentially templates
that will be used by the "mvn archetype:generate" command to create a new
project. The developer would then be free to apply whatever license they
want to their newly generated portlet project.

It's totally fine not to have license headers in archetype-generated
files like HelloWorldPortlet.java.
My concerns were at these files, which are the archetype source
itself, not generated ones, for instance:
- pom.xml
- src/main/resources/META-INF/maven/archetype-metadata.xml
- src/main/resources/META-INF/maven/archetype.xml

I think those three files must have license headers.


Regarding log4j, I would be happy to migrate to the SLF4J API in a future
dot release.

Cool!


Please let me know whether or not I have addressed your concerns to your
satisfaction.

Without proper license headers in those three files, I don't think
that's qualified for a proper Apache release.
Sometimes we miss license headers in some source files unintentionally
in a bigger project, which might be excused, but in this case, it's
obvious that we totally forgot adding the headers in the whole
project, IMHO.

Regards,

Woonsan



Best Regards,

Neil


On 4/24/17 11:46 PM, Woonsan Ko wrote:

On Thu, Apr 20, 2017 at 1:44 PM, Neil Griffin
<neil.grif...@portletfaces.org> wrote:

Dear Apache Portals Pluto Team and community,

I have staged a release candidate for the new Apache Portals Pluto Maven
Archetypes 3.0.0 release,
which includes the following two artifacts:

<groupId>org.apache.portals.pluto.archetype</groupId>
<artifactId>bean-portlet-archetype</artifactId>
<packaging>maven-archetype</packaging>

<groupId>org.apache.portals.pluto.archetype</groupId>
<artifactId>generic-portlet-archetype</artifactId>
<packaging>maven-archetype</packaging>

Please review the release candidate which is available from the following
maven staging repository:
https://repository.apache.org/content/repositories/orgapacheportals-1016


This link doesn't work for me. I managed to find the staging repo at
https://repository.apache.org/#stagingRepositories.
It shows "404 - Repository "orgapacheportals-1016 (staging: open)"
[id=orgapacheportals-1016] exists but is not exposed" when clicked on,
regardless whether or not I signed in https://repository.apache.org/.
Does anyone know the reason?


This vote is open for the next 72 hours.

Please cast your vote:


I'm not sure if it is desirable to release this. When I downloaded the
bean-portlet-archetype-3.0.0-source-release.zip from the Nexus, I
could hardly find source files with Apache License header [1]. Most
files are missing the license header.
Wouldn't it be more desirable to correct this issue first?

And, one minor thing to remark is that the archetype is using log4j
v1, neither slf4j nor log4j v2. AFAIK, pluto project itself and its
submodules such as container have used slf4j as logging API and log4j
as a default binding. Not a major, but just something to consider
later perhaps...

Kind regards,

Woonsan

[1] http://www.apache.org/legal/src-headers.html#headers


[ ] +1 for Release
[ ]  0  for Don't care
[ ] -1 Don't release (do provide a reason then)

Thanks,

Neil




Reply via email to