Sahoo et al,
I would like to make this change to glassfish/pom.xml so the jar file
names match the modules dir (see reasons in my initial message below).
I'll wait for comments if anyone can think of a reason *not* to do it.
Lloyd
MB2:code lloyd$ svn diff pom.xml
Index: pom.xml
===================================================================
--- pom.xml (revision 22954)
+++ pom.xml (working copy)
@@ -199,6 +199,9 @@
<build>
<defaultGoal>install</defaultGoal>
<sourceDirectory>src/main/java</sourceDirectory>
+
+ <!-- make the target/*.jar names match the name as found in
installed modules/ -->
+ <finalName>${project.artifactId}</finalName>
<!-- Begin: Parent Plugin Management Section -->
<pluginManagement>
Lloyd
On Sep 25, 2008, at 12:24 PM, Sahoo wrote:
> Maven is smart; when it copies files to repo (local and remote), it
> copies as ${artifactId}-${version}.${extension}.
>
> Thanks,
> Sahoo
>
> Marina Vatkina wrote:
>> Sahoo,
>>
>> At what point are jars published to the maven repo? Is it ok if we
>> publish them without the version in the name?
>>
>> thanks,
>> -marina
>>
>> Lloyd Chambers wrote:
>>> Thanks!
>>>
>>> I didn't realize that it could be inherited so easily. Let me try
>>> it and if it indeed works as suggested, I'll commit the parent
>>> pom.xml. Could there be other side-effects to doing this (eg
>>> other developers with expectations not unlike mine?)
>>>
>>> I tried it in common/ and it looks good:
>>>
>>> MB2:common lloyd$ ls */target/*.jar
>>> amx-api/target/amx-api-sources.jar glassfish-ee-api/
>>> target/ glassfish-ee-api-sources.jar
>>> amx-api/target/amx-api.jar glassfish-ee-api/
>>> target/glassfish-ee- api.jar
>>> amx-impl/target/amx-impl-sources.jar glassfish-
>>> naming/target/ glassfish-naming-sources.jar
>>> amx-impl/target/amx-impl.jar glassfish-naming/
>>> target/glassfish- naming.jar
>>> annotation-framework/target/annotation-framework-sources.jar
>>> internal- api/target/internal-api-sources.jar
>>> annotation-framework/target/annotation-framework.jar
>>> internal-api/ target/internal-api.jar
>>> common-util/target/common-util-sources.jar mbeanserver/
>>> target/ glassfish-mbeanserver-sources.jar
>>> common-util/target/common-util.jar mbeanserver/
>>> target/glassfish- mbeanserver.jar
>>> container-common/target/container-common-sources.jar
>>> stats77/target/ stats77-sources.jar
>>> container-common/target/container-common.jar stats77/
>>> target/ stats77.jar
>>> glassfish-api/target/glassfish-api-10.0.419.jar
>>>
>>>
>>> Lloyd
>>>
>>> ..............................................
>>> Lloyd Chambers
>>> lloyd.chambers_at_sun.com
>>> GlassFish team, LSARC member
>>>
>>> On Sep 25, 2008, at 11:20 AM, Sahoo wrote:
>>>
>>>> Yes, that can be achieved by having something like this:
>>>> <build><finalName>${project.artifactId}</finalName></build>
>>>> in pom.xml. You may be able to set this in parent POM (i.e., v3/
>>>> pom.xml) and all other poms may just inherit the behavior.
>>>>
>>>> Please feel free to try this out.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Lloyd Chambers wrote:
>>>>
>>>>> In the last day or two a change was made where the jar-file
>>>>> names in glassfish/modules became (for example) "amx-impl.jar"
>>>>> instead of "amx-impl-10.0-SNAPSHOT.jar".
>>>>>
>>>>> My development process consists of:
>>>>> 1) a full build, installing the server
>>>>> 2) builds in individual module directories
>>>>>
>>>>> Until this change, I could just do "cp common/target/*.jar /
>>>>> glassfish/modules" and I instantly had an updated install for
>>>>> every module in 'common' which I could then test.
>>>>>
>>>>> With the name change, the 'target' directory does *not* contain
>>>>> a jar file with the correct (simplified) name as found in the
>>>>> 'modules' directory. So the "target/*.jar" algorithm fails,
>>>>> and I'm forced to hard-code jar file names for each and every
>>>>> module.
>>>>>
>>>>> Maybe I'm missing something here, but it would be very helpful
>>>>> to make each module's target directory contain the jar file as
>>>>> actually named in the modules directory.
>>>>>
>>>>> Lloyd
>>>>>
>>>>> ..............................................
>>>>> Lloyd Chambers
>>>>> lloyd.chambers_at_sun.com
>>>>> GlassFish team, LSARC member
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>