Hi team,
like you should know, we a reusing now maven 2.
in the first stage, we've done some pom.xml files using the groupId jguard.
it is simple and permits to be viewed very quickly in remote repositories.
but according to the maven convention (http://maven.apache.org/guides/mini/guide-naming-conventions.html), we should use instead 'net.sf.jguard' .
i've seen some projects in ibiblio repository, which has used the first way, but have changed to the official maven way(via relocation mechanism).also, i don't know if ibiblio maintainers will accept jguard as a groupid.
sdo, to avoid any future issues, i propose to change our groupId to 'net.sf.jguard', to publish our first archives in the right way.
what is your opinion about it?
are you agree?
cheers,
Charles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
only update your sources from svn (i will modify pom.xml files in a couple of minutes).
this groupId permits to identify the jars we deliver on remote repositories, and ca be referenced in other projects which are using jGuard.
so,like we've not yet published jGuard jars on maven2 remote repositories, we are safe.
:-p
cheers,
Charles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Vincent,
we need to release jguard stuff on both locations:
sourceforge with the assembly:assembly plugin, and
use "mvn source:jar javadoc:jar repository:bundle-create" for create a bundle for each module (this plugin does not yet support multi-modules project.
i've tried to create the bundle for jguard-core, but i've got some issues:
firstly, it requires a description: i've added the required markup in the jguard-core pom's file.
but after, it raise and exception, by saying:
"The attribute "Specification-Title" may not occur more than once in the same section".
it seems to be raised by the jar plugin called by the repository plugin.
have you ever successfully created a bundle dedicated to maven 2 repository?
that's the last step before a beta release.
cheers,
Charles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Charles,
it seems that the problem is comming from the jar plugin preferences defined in jguard parent project. jguard parent project's pom.xml defined the properties for the jar plugin and add <Specification-Title>${pom.artifactId}</Specification-Title>.
So when maven runs, it adds to MANIFEST.MF the standard specification-Title for what description tag in pom contains but then it uses preferences saying that Specifcation-Title must be artifactId. The two are added generating a invalid Manifest.mf.
One more thing about jguard poms. For now, build versions are defined in a property in parent's pom. We did that to facilitate the version number change but this is not a standard way to do and this could generate problems. For example, if you want to run a build on only one project, some tasks may fail. It think we should replace all ${buildVersion} property by the real version number. Version number change are not so frequent.
What do you think about that ?
See you,
Vincent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Vincent,
thank you for the bug analysis, it will help me to solve it(if i succeed, i will commit the updated pom).
abiout the buildVersion, i'm agree with you because this way raises so many issues.
cheers,
Charles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi vincent,
i've tried several ways to solve this issue, but it resists....
:-(
i've tried to remove some maven-jar plugin reference in pom.xml from jguard-core module, jguard module, or both, without succeed. i've also remove the specification title manifest-entry without succeess...
i've read that sometimes special line feed/crraige return character in description ca raise an issue like that...
maybe some encoding issue can be also present....
i'm blocked with this problem....
:-((
Charles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
some hints to progress on solving the problem:
the problem is raised by the jar plugin.
so, 'mvn jar:jar' raise the same problem.
if i execute this instruction in the 'jguard' module and put this plugin configuration in its pom, all is fine:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Specification-Version>1.00-beta-1</Specification-Version>
<Specification-Vendor>jguard</Specification-Vendor>
<Implementation-Vendor>jguard</Implementation-Vendor>
</manifestEntries>
</archive>
</configuration>
</plugin>
note i've removed the entry about specification-title.
but the same configuration into 'jguard-core' module fails....
Charles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi team,
like you should know, we a reusing now maven 2.
in the first stage, we've done some pom.xml files using the groupId jguard.
it is simple and permits to be viewed very quickly in remote repositories.
but according to the maven convention (http://maven.apache.org/guides/mini/guide-naming-conventions.html), we should use instead 'net.sf.jguard' .
i've seen some projects in ibiblio repository, which has used the first way, but have changed to the official maven way(via relocation mechanism).also, i don't know if ibiblio maintainers will accept jguard as a groupid.
sdo, to avoid any future issues, i propose to change our groupId to 'net.sf.jguard', to publish our first archives in the right way.
what is your opinion about it?
are you agree?
cheers,
Charles.
Hi
We must folow the conventions, so I agree.
One question, what we must to do when you update the "groupId"?
cheers
Maxi
only update your sources from svn (i will modify pom.xml files in a couple of minutes).
this groupId permits to identify the jars we deliver on remote repositories, and ca be referenced in other projects which are using jGuard.
so,like we've not yet published jGuard jars on maven2 remote repositories, we are safe.
:-p
cheers,
Charles.
Good idea to do it now.
See you,
Vincent
Hi Vincent,
we need to release jguard stuff on both locations:
sourceforge with the assembly:assembly plugin, and
use "mvn source:jar javadoc:jar repository:bundle-create" for create a bundle for each module (this plugin does not yet support multi-modules project.
i've tried to create the bundle for jguard-core, but i've got some issues:
firstly, it requires a description: i've added the required markup in the jguard-core pom's file.
but after, it raise and exception, by saying:
"The attribute "Specification-Title" may not occur more than once in the same section".
it seems to be raised by the jar plugin called by the repository plugin.
have you ever successfully created a bundle dedicated to maven 2 repository?
that's the last step before a beta release.
cheers,
Charles.
Hi Charles,
it seems that the problem is comming from the jar plugin preferences defined in jguard parent project. jguard parent project's pom.xml defined the properties for the jar plugin and add <Specification-Title>${pom.artifactId}</Specification-Title>.
So when maven runs, it adds to MANIFEST.MF the standard specification-Title for what description tag in pom contains but then it uses preferences saying that Specifcation-Title must be artifactId. The two are added generating a invalid Manifest.mf.
One more thing about jguard poms. For now, build versions are defined in a property in parent's pom. We did that to facilitate the version number change but this is not a standard way to do and this could generate problems. For example, if you want to run a build on only one project, some tasks may fail. It think we should replace all ${buildVersion} property by the real version number. Version number change are not so frequent.
What do you think about that ?
See you,
Vincent.
Hi Vincent,
thank you for the bug analysis, it will help me to solve it(if i succeed, i will commit the updated pom).
abiout the buildVersion, i'm agree with you because this way raises so many issues.
cheers,
Charles.
Hi vincent,
i've tried several ways to solve this issue, but it resists....
:-(
i've tried to remove some maven-jar plugin reference in pom.xml from jguard-core module, jguard module, or both, without succeed. i've also remove the specification title manifest-entry without succeess...
i've read that sometimes special line feed/crraige return character in description ca raise an issue like that...
maybe some encoding issue can be also present....
i'm blocked with this problem....
:-((
Charles.
some hints to progress on solving the problem:
the problem is raised by the jar plugin.
so, 'mvn jar:jar' raise the same problem.
if i execute this instruction in the 'jguard' module and put this plugin configuration in its pom, all is fine:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Specification-Version>1.00-beta-1</Specification-Version>
<Specification-Vendor>jguard</Specification-Vendor>
<Implementation-Vendor>jguard</Implementation-Vendor>
</manifestEntries>
</archive>
</configuration>
</plugin>
note i've removed the entry about specification-title.
but the same configuration into 'jguard-core' module fails....
Charles.